3

I'm trying to gauge password strength assuming that the attacker has a hash of my password. Can anyone cite some realistic contemporary rates at which someone could perform various hashes? I know most sites use unnecessarily weak hashes like MD5 of SHA-1, so rates for these would be the most relevant.

Improve this question
2
  • 1
    Keep in mind that if someone really wants your password, they can use thousands (tens of thousands? hundreds of thousands?) of nodes to hack it (either by purchasing computer time or enlisting a botnet), so for whatever complexity you think is safe, you ought to multiply it by a million.
    – Johnny
    Jun 28, 2013 at 14:51
  • 1
    Also, don't forget that most "estimate my password's strength" scripts and guides are quite naive compared to a skilled attacker (who, for instance, knows about keyboard walks and "a"->"@" substitutions and stuff). You can only guarantee the entropy of your password is what it appears to be if you wrote a script to generate it based on /dev/random or something.
    – Stephen Bachelor
    Jun 28, 2013 at 18:22

1 Answer 1

Reset to default
12

For a simple invocation of MD5 or SHA-1, a realistic rate is between 1 and 10 billions of passwords per second. That's what can be achieved with a good GPU. Furthermore, if the hashing is not salted, then the attacker can share the effort between several attack sessions, usually using precomputed tables (e.g. rainbow tables): an attacker, somewhere, had to hash gazillions of possible passwords once, but then the resulting tables can be applied to thousands of hashes with only a small cost.

If the hash function is proper (as described in this answer), then it uses a slowdown parameter which makes the function as slow as can be wished for. Slowness impacts both the defender (the honest server who uses the hash to authenticate users) and the attacker. We could imagine, for instance, that the defender is ready to invest 10ms worth of his own CPU on each hashing instance, which means that the defender can handle 100 password hashes per second. The attacker can throw more PC at the issue, with multiple cores, and possibly use specialized hardware (GPU, FPGA...), which may give him some boost; let's say that the attacker can be 100 times more efficient at the password hashing than the defender, leading to brute force performance of 10000 guesses per second.

The boost that the attacker can obtain through specialized hardware depends on the function (e.g. a GPU will be good for attacking PBKD2/SHA-256, not as much for attacking bcrypt). How much hardware the attacker will be able to throw at the problem also depends on external parameters (his budget, his motivation...). The slowness used by the defender is a trade-off, because increased slowness uses server resources and may make it more vulnerable to denial-of-service attacks.

Improve this answer
4
  • Thanks for the detailed response. Just for clarity, I'm not implementing a service myself, I'm just trying to gauge how strong my own password is on other people's services, given reasonable assumptions about what they're doing to protect it (i.e., not that much). None the less, your response was very informative, so thanks!
    – brianmearns
    Jun 28, 2013 at 13:53
  • 3
    On my dual 6970 setup with oclhashcat: 3B sha, 8B md5, 1.1B sha256
    – Filip Haglund
    Jun 28, 2013 at 14:31
  • 2
    I'm glad that someone has finally mentioned that expensive hashing generates a DoS vector.
    – Darius Jahandarie
    Jun 28, 2013 at 17:08
  • Use a "good enough" hash, and use both salt and pepper, and more spices if you can - try to not fit into any of the common formats or there will be rainbow tables for them already, and/or programs that already know how to guess them efficiently.
    – Filip Haglund
    Jun 29, 2013 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .