6 ms·

A tip I learned recently: if you see a database with a simple hash with no salt(md5, sha256…) like this, and you want to migrate to a secure password hashing fu

by Aissen 5y ago

A tip I learned recently: if you see a database with a simple hash with no salt(md5, sha256…) like this, and you want to migrate to a secure password hashing function (bcrypt, argon2…) you don't need to wait for the users to re-login: simply do bcrypt(md5(password)) immediately, and delete the old hashes, and you get higher security.

stevewodil 5y ago
Slightly related, in order to prevent super long passwords from eating up CPU time is it better to hash using sha256 before argon/bcrypt so that the length is constant, or is it better to limit password length to some arbitrary number like 64 characters
- l-lousy 5y ago
  I think an average user password would be shorter than a sha256 hash no?
  - LeifCarrotson 5y ago
    Bcrypt truncates to 72 bytes, so it's kind of irrelevant IMO. Whether your average length is 12 or 20 or 64 bytes doesn't matter much. I expect the parent's concern came from experience with PBKDF2, where the length is unbounded. It's good to consider possible denial of service attacks: if someone submits an enormous 1 MB password a PBKDF2 hasher can be knocked offline for 60s. Sha256 will quickly crunch that attack to a more manageable length.
    - stevewodil 5y ago
      Exactly this, it’s a vector for DOS
- 8organicbits 5y ago
  > Many implementations of bcrypt truncate the password to the first 72 bytes, following the OpenBSD implementation. https://en.m.wikipedia.org/wiki/Bcrypt https://en.m.wikipedia.org/wiki/Bcrypt This sounds undesirable to me, so I'd support sha256 and an alternative. I'd also recommend adding a max password length to any API. No point in allowing million character passwords.
  - 8organicbits 5y ago
    I'm guessing folks are reading that as endorsement or sha256 over bcrypt. In context with the above post, this is sha256 over truncation.
- DrBoring 5y ago
  > to prevent super long passwords from eating up CPU time Is that why websites sometimes have low maximum password length requirements ? Ex: must be less than 20 characters.
  - ThreeToZero 5y ago
    Super long is >100 character passwords. Not much point: either the hash function is broken or some other hack will happen before humanity develops enough compute power to crack 100 char bcrypt passwords. Websites (like some banks used to) that have less-than 20 char limits for passwords are purely bad security strategy.
    - mooreds 5y ago
      You know what the worst is? When they limit you to, say, 20 or 32 characters, but accept a longer password and silently truncate it! I've run across that at least once and it was a total pain to troubleshoot and figure out.
    - GordonS 5y ago
      The number of sites that restrict passwords to 20 characters drives me nuts! There needs to be a limit, yes, but surely something like 100 characters, or even 50, would be more sensible.
      - BlueTemplar 5y ago
        And it's the same websites that tend to use the bad practice of forcing the use of 2-4 "types" of characters...
    - userbinator 5y ago
      like some banks used to Banks all have systems that will stop you from attempting to bruteforce them.
  - colejohnson66 5y ago
    The CPU usage difference between a hash on 20 bytes vs 100 (assuming ASCII) can't be that bad, can it?
- tzs 5y ago
  I've been tempted a few times to simply use salt and a single iteration SHA-256 to store passwords, and put something like this on the account creation and password change screens: > If you care about the security of your account use a 20+ character random password and do not reuse that password at any other sites. There are several excellent password managers that can generate and remember such a password for you and make it easy to use. Here's a list: <link to list of password managers>. > We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and <list of punctuation>. Set your password generator to length 20+ and to use mixed case, digits, and symbols and you will be fine. > If you think you might have to manually type this password at some point, you can use a reduced character set with a longer password. If you use just mixed case letters and digits make the password 22+ characters long. If you use just mixed case letters make it 23+ characters. Letters all of the same case? Make it 28+ characters. 32+ characters of hex is fine, too. Heck, you can make it all digits if you use at least 39 of them. > If your password manager offers other options, such as patterns like groups of digits or pronounceable syllables separated by some symbol, that too is fine as long as you make it long enough. Make it long enough that your password manager gives it its highest strength rating. > The exact upper limit on password length that our password entry fields allow might vary from time to time as we update the site, but will always be at least 64 characters.
- mooreds 5y ago
  What's wrong with super long passwords eating up CPU time? Can't imagine it is that prevalent with normal users and there are other ways to deal with it if it is a vector for a DOS attack (rate-limiting the number of registrations or logins, for example). NIST says there's no reason to limit password length any more[0]: "Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets." 0: https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html
dabeledo 5y ago
> simply do bcrypt(md5(password)) This could also be problematic. Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ https://www.youtube.com/watch?v=OQD3qDYMyYQ
- mpeg 5y ago
  Honestly, not as a big a deal as some people make it. First off, you'd have to assume the attacker knows the bcrypt hashes are bcrypt(md5(password)) – an attacker wouldn't always know this Also it assumes there is password reuse, but that the password is strong enough that the md5 is uncracked.
  - Perseids 5y ago
    I'm also not quite sure about the circumstances where that would be relevant, but on the StackExchange a sibling comment found there is this further explanation: > > I know I'm probably stupid but... how is this different from a dictionary attack? Instead of trying a list of known passwords, you try their md5s. If the md5 hasn't been cracked before, chances are that the password is strong enough to resist being cracked now. – nobody Jul 17 '20 at 14:55 > Because there are plenty of MD5s in the wild that A) just happen to not have been cracked yet because they weren't interesting enough to stand out, but B) once an attacker can figure out that that MD5 is inside a really interesting, high-value-target bcrypt, they might spend a lot more effort to crack that MD5. So it's not just a dictionary attack; it's a dictionary attack of passwords that are currently unknown but might be crackable with additional effort. And that effort is much less than trying to crack that password if it was only inside a pure bcrypt. – Royce Williams Jul 17 '20 at 15:00 https://security.stackexchange.com/questions/234794/is-bcryptstrtolowerhexmd5pass-ok-for-storing-passwords#comment481066_234795 https://security.stackexchange.com/questions/234794/is-bcryp... So the assumption is: There is a breach A of an low-interest target with MD5 hashes and a breach B of a high-interest target with BCrypt(MD5) hashes. As A is not interesting enough, people don't invest the time to crack A's MD5s. But as B is super interesting they will use A as a dictionary source to then know on which MD5s they should invest a high amount of time, as it will help them crack the high-interest target B. Note that no specific user association takes place, like in the presentation about password shucking by Sam Croley (above Youtube link), where usernames/emails of A and B are correlated. I think this is a bit more plausible than Croley's take on it. Because if I have identified a high interest individual, I would already invest a lot time to crack the MD5 password. And yes, what you said bears repeating: All of this attack lives in the small space where the password is too strong to be cracked from a simple MD5 hash when you are mildly interested but not strong enough to prevent cracking when you are deeply interested – for varying degrees of mildly and deeply interested. Overall I would like to read about real world examples where this made the difference and how that password happened to fall into that region.
asddubs 5y ago
for md5, you could also download some common password lists and rehash at least the ones you can "crack"
fps-hero 5y ago
Great idea, but seeing as you are rearchitecting you might as well add the salt to the MD5 while you are at it.
danhoule 5y ago
I believe that this is a great idea but I was kind of wondering why people are not resorting to this method?

by Aissen 5y ago

stevewodil 5y ago

Slightly related, in order to prevent super long passwords from eating up CPU time is it better to hash using sha256 before argon/bcrypt so that the length is constant, or is it better to limit password length to some arbitrary number like 64 characters

l-lousy 5y ago
I think an average user password would be shorter than a sha256 hash no?
- LeifCarrotson 5y ago
  Bcrypt truncates to 72 bytes, so it's kind of irrelevant IMO. Whether your average length is 12 or 20 or 64 bytes doesn't matter much. I expect the parent's concern came from experience with PBKDF2, where the length is unbounded. It's good to consider possible denial of service attacks: if someone submits an enormous 1 MB password a PBKDF2 hasher can be knocked offline for 60s. Sha256 will quickly crunch that attack to a more manageable length.
  - stevewodil 5y ago
    Exactly this, it’s a vector for DOS
8organicbits 5y ago
> Many implementations of bcrypt truncate the password to the first 72 bytes, following the OpenBSD implementation. https://en.m.wikipedia.org/wiki/Bcrypt https://en.m.wikipedia.org/wiki/Bcrypt This sounds undesirable to me, so I'd support sha256 and an alternative. I'd also recommend adding a max password length to any API. No point in allowing million character passwords.
- 8organicbits 5y ago
  I'm guessing folks are reading that as endorsement or sha256 over bcrypt. In context with the above post, this is sha256 over truncation.
DrBoring 5y ago
> to prevent super long passwords from eating up CPU time Is that why websites sometimes have low maximum password length requirements ? Ex: must be less than 20 characters.
- ThreeToZero 5y ago
  Super long is >100 character passwords. Not much point: either the hash function is broken or some other hack will happen before humanity develops enough compute power to crack 100 char bcrypt passwords. Websites (like some banks used to) that have less-than 20 char limits for passwords are purely bad security strategy.
  - mooreds 5y ago
    You know what the worst is? When they limit you to, say, 20 or 32 characters, but accept a longer password and silently truncate it! I've run across that at least once and it was a total pain to troubleshoot and figure out.
  - GordonS 5y ago
    The number of sites that restrict passwords to 20 characters drives me nuts! There needs to be a limit, yes, but surely something like 100 characters, or even 50, would be more sensible.
    - BlueTemplar 5y ago
      And it's the same websites that tend to use the bad practice of forcing the use of 2-4 "types" of characters...
  - userbinator 5y ago
    like some banks used to Banks all have systems that will stop you from attempting to bruteforce them.
- colejohnson66 5y ago
  The CPU usage difference between a hash on 20 bytes vs 100 (assuming ASCII) can't be that bad, can it?
tzs 5y ago
I've been tempted a few times to simply use salt and a single iteration SHA-256 to store passwords, and put something like this on the account creation and password change screens: > If you care about the security of your account use a 20+ character random password and do not reuse that password at any other sites. There are several excellent password managers that can generate and remember such a password for you and make it easy to use. Here's a list: <link to list of password managers>. > We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and <list of punctuation>. Set your password generator to length 20+ and to use mixed case, digits, and symbols and you will be fine. > If you think you might have to manually type this password at some point, you can use a reduced character set with a longer password. If you use just mixed case letters and digits make the password 22+ characters long. If you use just mixed case letters make it 23+ characters. Letters all of the same case? Make it 28+ characters. 32+ characters of hex is fine, too. Heck, you can make it all digits if you use at least 39 of them. > If your password manager offers other options, such as patterns like groups of digits or pronounceable syllables separated by some symbol, that too is fine as long as you make it long enough. Make it long enough that your password manager gives it its highest strength rating. > The exact upper limit on password length that our password entry fields allow might vary from time to time as we update the site, but will always be at least 64 characters.
mooreds 5y ago
What's wrong with super long passwords eating up CPU time? Can't imagine it is that prevalent with normal users and there are other ways to deal with it if it is a vector for a DOS attack (rate-limiting the number of registrations or logins, for example). NIST says there's no reason to limit password length any more[0]: "Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets." 0: https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html

dabeledo 5y ago

> simply do bcrypt(md5(password)) This could also be problematic. Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ https://www.youtube.com/watch?v=OQD3qDYMyYQ

mpeg 5y ago
Honestly, not as a big a deal as some people make it. First off, you'd have to assume the attacker knows the bcrypt hashes are bcrypt(md5(password)) – an attacker wouldn't always know this Also it assumes there is password reuse, but that the password is strong enough that the md5 is uncracked.
- Perseids 5y ago
  I'm also not quite sure about the circumstances where that would be relevant, but on the StackExchange a sibling comment found there is this further explanation: > > I know I'm probably stupid but... how is this different from a dictionary attack? Instead of trying a list of known passwords, you try their md5s. If the md5 hasn't been cracked before, chances are that the password is strong enough to resist being cracked now. – nobody Jul 17 '20 at 14:55 > Because there are plenty of MD5s in the wild that A) just happen to not have been cracked yet because they weren't interesting enough to stand out, but B) once an attacker can figure out that that MD5 is inside a really interesting, high-value-target bcrypt, they might spend a lot more effort to crack that MD5. So it's not just a dictionary attack; it's a dictionary attack of passwords that are currently unknown but might be crackable with additional effort. And that effort is much less than trying to crack that password if it was only inside a pure bcrypt. – Royce Williams Jul 17 '20 at 15:00 https://security.stackexchange.com/questions/234794/is-bcryptstrtolowerhexmd5pass-ok-for-storing-passwords#comment481066_234795 https://security.stackexchange.com/questions/234794/is-bcryp... So the assumption is: There is a breach A of an low-interest target with MD5 hashes and a breach B of a high-interest target with BCrypt(MD5) hashes. As A is not interesting enough, people don't invest the time to crack A's MD5s. But as B is super interesting they will use A as a dictionary source to then know on which MD5s they should invest a high amount of time, as it will help them crack the high-interest target B. Note that no specific user association takes place, like in the presentation about password shucking by Sam Croley (above Youtube link), where usernames/emails of A and B are correlated. I think this is a bit more plausible than Croley's take on it. Because if I have identified a high interest individual, I would already invest a lot time to crack the MD5 password. And yes, what you said bears repeating: All of this attack lives in the small space where the password is too strong to be cracked from a simple MD5 hash when you are mildly interested but not strong enough to prevent cracking when you are deeply interested – for varying degrees of mildly and deeply interested. Overall I would like to read about real world examples where this made the difference and how that password happened to fall into that region.

asddubs 5y ago

for md5, you could also download some common password lists and rehash at least the ones you can "crack"

fps-hero 5y ago

Great idea, but seeing as you are rearchitecting you might as well add the salt to the MD5 while you are at it.

danhoule 5y ago

I believe that this is a great idea but I was kind of wondering why people are not resorting to this method?