30 ms·

They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted

by robomc 7y ago

They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify the work of a time consuming attack on the hashes.

bigiain 7y ago
Also "Some level of production access" could easily include the ability for the attacker to intercept and exfiltrate passwords as users log in.
adrianN 7y ago
I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?
- lucb1e 7y ago
  The cost? That depends on the password. How long does it take to crack 123456? That depends on the parameters. In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark than the 20 mark, but I expect stackoverflow to be on the good end. The current state of the art is Argon2, with scrypt second and bcrypt/pbkdf2 tied for third. The first two have memory hardness, and the first one is the standard chosen in the password hashing algorithm competition. The third is still acceptable because most developers still go for a salted single hash like sha256. Somehow they got the salting method, but I'd rather they break all identical passwords at the same time (they weren't that strong anyway if they're shared between more than one person) than that they crack only a tiny percentage because of the cost. Slowness helps more than salting, yet as a pentester I see more of the latter than the former. So I'd rather recommend something available for their platform as a good third choice than them going "meh, effort" and not implementing the recommendation.
  - bmn__ 7y ago
    > The current state of the art is Argon2 Details for the interested implementer: there's a lot of bad software floating around out there, be careful and do your due diligence. Use the argon2id function. If the language binding does not expose the argon2id function, but only argon2i and argon2d, then it's outdated, avoid. If the library has not been updated past 2016 (argon2 v1.3), it's vulnerable, avoid. (Some language bindings ship with an embedded library.) Language bindings to the argon2 library do not document how to pick good parameters because language binding authors do not understand nor care about security, the suggestions in the synopses are laughably undervalued. Compare with the expert recommendations in https://password-hashing.net/argon2-specs.pdf https://password-hashing.net/argon2-specs.pdf chap. 6.4, 8, 9 and https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 . Algorithm for picking the correct values on the target server hardware: const PASSPHRASE := 6 random words from dictionary const SALT := 16 bytes from urandom const DURATION := 0.5 ### or greater; this is the maximum amount ### you are willing for your user to wait mut T_COST := 1 mut M_FACTOR := concat(4096, 'M') const PARALLELISM := `nproc` const TAG_SIZE := 16 ### bytes, or 128 bits while { const TIMER := benchtime argon2id( PASSPHRASE, SALT, T_COST, M_FACTOR, PARALLELISM, TAG_SIZE ) if TIMER > DURATION { if 1 === T_COST { reduce M_FACTOR ### e.g. divide by a constant jump to top of while } else { jump out of while } } print T_COST, concat(M_FACTOR, 'M'), TIMER T_COST := T_COST + 1 }
- tialaramex 7y ago
  "Cracking" isn't a meaningful operation for these algorithms. You would need to try guessing, if you don't know anything about the password then you need to guess all possible passwords until you get the right one or a collision (the pigeon hole principle applies) If my password is "password" you can probably guess that almost instantly no matter what scheme is used. If my password is 32 characters of random base64 output then it wouldn't matter if the scheme is MD5($password) you won't guess it. Schemes like PBKDF2 and bcrypt trade something useful in the middle, if your password is mediocre they make it too hard to bother guessing. But you'd need to define how mediocre it is to get a meaningful estimate.
jve 7y ago
Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier than he actually is. But he's right. MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 or Bcrypt would be a better choice. https://blog.codinghorror.com/youre-probably-storing-passwords-incorrectly/ https://blog.codinghorror.com/youre-probably-storing-passwor... Another topic on passwords: https://blog.codinghorror.com/the-dirty-truth-about-web-passwords/ https://blog.codinghorror.com/the-dirty-truth-about-web-pass...
- tgsovlerkhgsel 7y ago
  > MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 For the purpose of hashing passwords, there's no significant difference between MD5 and SHA-2. Both are awful choices. Edit: Actually, SHA-2 may be worse because CPUs have hardware acceleration and thus the attacker may be able to crack it somewhat faster than MD5.
  - zenexer 7y ago
    It’s definitely not worse—MD5 is faster with GPUs—but plain SHA-2 isn’t much better, either.
- dagenix 7y ago
  > SHA-2 or Bcrypt would be a better choice. As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.
  - TeMPOraL 7y ago
    Sure. But that advice was written 12 years ago. I'd be surprised if they didn't update their password storage since then.

by robomc 7y ago

bigiain 7y ago

Also "Some level of production access" could easily include the ability for the attacker to intercept and exfiltrate passwords as users log in.

adrianN 7y ago

I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?

lucb1e 7y ago
The cost? That depends on the password. How long does it take to crack 123456? That depends on the parameters. In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark than the 20 mark, but I expect stackoverflow to be on the good end. The current state of the art is Argon2, with scrypt second and bcrypt/pbkdf2 tied for third. The first two have memory hardness, and the first one is the standard chosen in the password hashing algorithm competition. The third is still acceptable because most developers still go for a salted single hash like sha256. Somehow they got the salting method, but I'd rather they break all identical passwords at the same time (they weren't that strong anyway if they're shared between more than one person) than that they crack only a tiny percentage because of the cost. Slowness helps more than salting, yet as a pentester I see more of the latter than the former. So I'd rather recommend something available for their platform as a good third choice than them going "meh, effort" and not implementing the recommendation.
- bmn__ 7y ago
  > The current state of the art is Argon2 Details for the interested implementer: there's a lot of bad software floating around out there, be careful and do your due diligence. Use the argon2id function. If the language binding does not expose the argon2id function, but only argon2i and argon2d, then it's outdated, avoid. If the library has not been updated past 2016 (argon2 v1.3), it's vulnerable, avoid. (Some language bindings ship with an embedded library.) Language bindings to the argon2 library do not document how to pick good parameters because language binding authors do not understand nor care about security, the suggestions in the synopses are laughably undervalued. Compare with the expert recommendations in https://password-hashing.net/argon2-specs.pdf https://password-hashing.net/argon2-specs.pdf chap. 6.4, 8, 9 and https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 . Algorithm for picking the correct values on the target server hardware: const PASSPHRASE := 6 random words from dictionary const SALT := 16 bytes from urandom const DURATION := 0.5 ### or greater; this is the maximum amount ### you are willing for your user to wait mut T_COST := 1 mut M_FACTOR := concat(4096, 'M') const PARALLELISM := `nproc` const TAG_SIZE := 16 ### bytes, or 128 bits while { const TIMER := benchtime argon2id( PASSPHRASE, SALT, T_COST, M_FACTOR, PARALLELISM, TAG_SIZE ) if TIMER > DURATION { if 1 === T_COST { reduce M_FACTOR ### e.g. divide by a constant jump to top of while } else { jump out of while } } print T_COST, concat(M_FACTOR, 'M'), TIMER T_COST := T_COST + 1 }
tialaramex 7y ago
"Cracking" isn't a meaningful operation for these algorithms. You would need to try guessing, if you don't know anything about the password then you need to guess all possible passwords until you get the right one or a collision (the pigeon hole principle applies) If my password is "password" you can probably guess that almost instantly no matter what scheme is used. If my password is 32 characters of random base64 output then it wouldn't matter if the scheme is MD5($password) you won't guess it. Schemes like PBKDF2 and bcrypt trade something useful in the middle, if your password is mediocre they make it too hard to bother guessing. But you'd need to define how mediocre it is to get a meaningful estimate.

jve 7y ago

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier than he actually is. But he's right. MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 or Bcrypt would be a better choice. https://blog.codinghorror.com/youre-probably-storing-passwords-incorrectly/ https://blog.codinghorror.com/youre-probably-storing-passwor... Another topic on passwords: https://blog.codinghorror.com/the-dirty-truth-about-web-passwords/ https://blog.codinghorror.com/the-dirty-truth-about-web-pass...

tgsovlerkhgsel 7y ago
> MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 For the purpose of hashing passwords, there's no significant difference between MD5 and SHA-2. Both are awful choices. Edit: Actually, SHA-2 may be worse because CPUs have hardware acceleration and thus the attacker may be able to crack it somewhat faster than MD5.
- zenexer 7y ago
  It’s definitely not worse—MD5 is faster with GPUs—but plain SHA-2 isn’t much better, either.
dagenix 7y ago
> SHA-2 or Bcrypt would be a better choice. As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.
- TeMPOraL 7y ago
  Sure. But that advice was written 12 years ago. I'd be surprised if they didn't update their password storage since then.