5 ms·

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in p

• gizmo686 11y ago
  You could delete the old hash and require users to generate a new one through the password reset mechanism. Generally you would want to combine both approaches, so that only users who do not log in during the transfer window have to deal with setting a new password.
• thedz 11y ago
  This wasn't the PW hashing fucntion. The new method hashes using the bcrypt of the password, which they do have.
  • bradleyjg 11y ago
    Bingo. All they had to do is delete all the login tokens. Users with what would have otherwise been a valid cookie would have had to re-log in, but that's a minor inconvenience that's expected to happen from time to time.
• encoderer 11y ago
  No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.
  • TallGuyShort 11y ago
    The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes. edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...
    • msbarnett 11y ago
      > The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes. The entropy isn't the significant problem with MD5. The problem is how damn fast you can perform 2 billion MD5 hashes on modern machines.
    • adevine 11y ago
      Entropy is not really the issue here. For a dictionary attack with a non-reversible hash, what matters is how computationally intensive it is to generate the hash. MD5 hashes can be generated very quickly, while bcrypt hashes take much, much longer to generate.
    • InclinedPlane 11y ago
      There are levels of vulnerability: 1: Vulnerability to a pre-computed table. This hits hard if you are using plain-old MD5 without a salt. 2: Vulnerability to a newly computed table. This will hit you if you use a global salt and a fast hashing/encryption algorithm. 3: Vulnerability to high throughput custom hardware. This will hit you if you use a fast hashing algorithm like MD5. Modern GPU-based algorithms can churn through hundreds of billions of hashes per second on fairly inexpensive hardware. Which means that attacking, say, 20 million accounts it's possible to run through billions of possible passwords (which means a full dictionary attack, the top million most common passwords, plus common ways of combining words to make passwords, plus every random alphanum string up to 9-10 digits) for each and every account in only a month of work. 4: Vulnerability to very weak passwords. This will hit you if you use a slow hashing algorithm and there's no global vulnerability because you use per-record salts (or bcrypt/scrypt). 4 is where you want to be, always. You can't protect against weak passwords, but you can make it expensive for weak passwords to be revealed, and prohibitively expensive for stronger passwords to be systematically cracked. The entropy of the hashes isn't really relevant since it's the repeatability of the hashing that's at issue. For example, the hash 7c6a180b36896a0a8c02787eeafb0e4c seems to have plenty of entropy, but since it's the MD5 of the string "password1" and you can just google that hash to find out that information, the theoretical entropy is moot.
  • nitrogen 11y ago
    Yes, in addition to migrating to pure bcrypt/scrypt at next login. I've implemented this migration strategy for two different web sites (not listed in my HN profile) with success.
  • sbov 11y ago
    Not so complicated if you plan for this sort of stuff ahead of time, or even at migration time. You can prepend your hashed fields with the algorithm used, and have a library that automatically handles them. This also makes generating test data easier, as our library has a "plaintext" hash type, so we can just insert "$plaintext$password" rather than having to run a hash on the password.
• syncsynchalt 11y ago
  No, you can re-hash the original hash you have, and add an additional check at login for new-hash(original-hash(password)).
• msbarnett 11y ago
  > I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No? No. Well, I mean, it's common to do that, but it's a bad idea and it's not necessary to keep all of those vulnerable hashes around. Say you have a bunch of MD5 password hashes stored, and you want to upgrade your password hashing to BCrypt. Don't wait for the user to login and rehash their plain text password. Instead, Bcrypt all the MD5s. The authentication mechanism is now BCrypt(MD5(plaintext)) == stored_bcrypt. Upgrade them to straight bcrypt on login.
  • mentat 11y ago
    That doesn't really have the same security properties as the original login information.
    • ajross 11y ago
      No, but it's resistant to parallel cracking, which is the hole being plugged.
    • msbarnett 11y ago
      > That doesn't really have the same security properties as the original login information. Well, obviously. For instance, it lacks the property of being trivially vulnerable to a GPU hashing the entire dictionary with a given salt in 30 seconds flat.
• knodi123 11y ago
  > that's the only time you have the PW in plain text Well, if the issue is that your hash is crackable.... ;-)