Focus on Linux
Re: Detecting Brute-Force and Dictionary attacks Nov 08 2006 05:22PM
Sebastiaan Veenstra (sebastiaan veenstra gmail com) (2 replies)
Re: Detecting Brute-Force and Dictionary attacks Nov 10 2006 01:43PM
Cy Schubert (Cy Schubert spqr komquats com)
Re: Detecting Brute-Force and Dictionary attacks Nov 09 2006 06:45PM
fabio (ctrlaltca libero it) (2 replies)
Re: Detecting Brute-Force and Dictionary attacks Nov 11 2006 04:19PM
Christian Jonassen (flyrev gmail com) (1 replies)
Re: Detecting Brute-Force and Dictionary attacks Nov 13 2006 07:35PM
Esteban RibičiÄ? (kisero gmail com)
Re: Detecting Brute-Force and Dictionary attacks Nov 10 2006 11:41PM
Greg Metcalfe (metcalfegreg qwest net) (1 replies)
Re: Detecting Brute-Force and Dictionary attacks Nov 13 2006 08:46PM
John Hall (silo xptr net)
Quoting Greg Metcalfe <metcalfegreg (at) qwest (dot) net [email concealed]>:

> On Thursday 09 November 2006 10:45, fabio wrote:
>> The idea is simple and good, but there's a problem in its
>> implementation: usually modern systems doesn't compare the password you
>> write with the saved password; instead, they compare an hash of your
>> password attempt with the saved hash of your current password. By
>> design, two similar string have strongly different hashes. So you can't
>> compare two hashes and say if they correspond to two similar words.
>> Greets,
>> Fabio
>> Sebastiaan Veenstra wrote:
>> > Hi,
>> >
>> > I didn't read the whole discussion about this issue but I came up with
>> > an idea which might be usefull to detect brute force attempt. By
>> > storing the passwords a certain user has used in the past along with
>> > the current password you could be able to compare to password (by
>> > pattern matching) used at the login attempts with the passwords list.
>> > If the password used differs significantly (this excludes typos) from
>> > the entries in the password list, there could be a possible brute
>> > force attempt. The reason for storing the previous passwords is that
>> > people tend to use every password they've used in the past when they
>> > forgot their password. Maybe this idea can be used along with the
>> > other methods of detecting brute force attempts. Anyway, it's just a
>> > random thought.
>> >
>> > Greets,
>> >
>> > Sebastiaan
> Most diplomatic of Fabio. Here's an example, using md5 hashing. Results will
> be similar, if any sort of valid crypto hash function is used.
> # echo 12345678 | md5sum
> 23cdc18507b52418db7740cbb5543e54
> # echo 12345679 | md5sum
> 0f4fd7804fbbcf67df5dc8ef8dc946fb
> The difficulty still lies in whether you choose to use modified binaries to
> record the submitted password (and there are huge downsides to doing this in
> anything other than a lab environment) or take the decision that x number of
> failed logins constitutes an attack. That's generally a wise move, depending
> upon your weighting scheme (time, IP number, etc.) and threat model.
> Even if you take the risky step of recording submitted passwords, you still
> have to write analysis software (and that's not nearly as simple as it
> sounds), and decide what to do with the results. There Are Issues.
> Personally, I'm against the whole idea of authenticating via passwords, at
> least as corporate password policies are currently and commonly implemented.
> But that's all about dealing with a threat model that may have nothing to do
> with your situation.
> Nothing said here constitutes good advice. Everything depends upon context.
> How you protect the Big Red Button will be far different than how you protect
> generic httpd logs.
> Regards,
> --
> Greg Metcalfe

It is my personal opinion that evaluating the passwords so closely,
such as mentioned in the previous email to Greg's, would open yourself
up to a far more complicated world than you might be thinking. By
evaluating the passwords, you are utilizing more resources than normal
during the authentication process. You would also open yourself to the
fact that the more system resources dedicated to this evaluation
process, the easier it would be for someone to perform a denial of
service attack to your system.
In the past, when I've had people attempting to attack my systems, the
easiest way to tell is the number of login attempts against the
frequency of the attempts. I typically end-up with a log full of
attempts to login, which makes it quite obvious.
To sum it up, make sure that if you do take this approach, you're
extremely defensive. You would want any evaluation you perform to be
done in the background to determine if there's an attack, not actively
while the login session is in progress.

John Hall

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus