Re: Detecting Brute-Force and Dictionary attacks

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.

Sebastiaan Veenstra wrote:

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.


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
# echo 12345679 | md5sum

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.

Greg Metcalfe

Relevant Pages

  • Re: What are my options for dictionary hashing?
    ... etc.  The types of that have been proven to be of poor quality. ... you can *always* find a better hash function that has a more ... hash function, since you can. ... Compare length + 2 characters: ...
  • Re: Suggestions for double-hashing scheme
    ... >> secondary hash function to 1/4 of the table size, ... > Hsieh is considered a laughing stock in many circles, ... Thats more typedefs than in all of bstrlib already. ... (Compare this to Bstrlib, whose influence ...
  • Re: Detecting Brute-Force and Dictionary attacks
    ... usually modern systems doesn't compare the password you ... password attempt with the saved hash of your current password. ... 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. ... 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. ...
  • Re: Performance of list vs. set equality operations
    ... When you compare two lists, *every* element of one of the lists is ... When you compare two sets, there's a loop over all the elements of the ... If this hash matches the hash for one or more elements in the ...
  • Re: How good are checksums?
    ... >checksum and compare file lengths. ... >duplicate very low. ... I use a fast Adlerian checksum. ... Your problem is similar to what to do with hash table collisions. ...