5 ms·

The real lesson here is that when you fix your mistakes, go back and fix your mistakes retroactively! AM used an insecure login token at one point, and 3 years

• artursapek 11y ago
  Updating them retroactively requires those users to log in again, doesn't it? I have had to do a similar update and you can't just update everyone's hashes retroactively. If you've properly hashed it, you need them to actually input their password again.
  • tempVariable 11y ago
    As far as I know, that is correct.[1] Any change, whether for work factor or algorithm in code still waits for the user to come back and attempt a login, at which point you update the database stored attributes and the hash. I think that if you can update a user's password without them inputting, then you have two problems. [1]not authoritative advice. edit: seems that comments suggest doing the md5(bcrypt(hash)) can be used to upgrade across the board
    • rurounijones 11y ago
      I thought that a while ago but then someone just pointed out that you bcrypt hash the MD5 hash and support two step (MD5 then bcrypt) until they login at which point you can rehash using only bcrypt.
      • artursapek 11y ago
        That's a much smarter approach. Never thought of that.
  • cruise02 11y ago
    It's possible to update everyone's password without them logging in. If the old storage was just MD5(password) and you want to update it to MD5(bcrypt(password)), you're out of luck. You need the plaintext password to make that change. If instead you change your new storage to MD5(bcrypt(MD5(password))), you can take all of the hashes currently in your database and update them at one time with MD5(bcrypt(old hash value)).
    • artursapek 11y ago
      Great point. Never occurred to me to do it that way.
  • jandrese 11y ago
    The proper solution would have been to flag the old passwords and require everyone to change them on the next login. After a couple of months you null out the remaining passwords and require anybody coming back to go through the password reset system.
  • yk 11y ago
    Depends, if your old hash is H1, then you can migrate to a scheme H2(H1(password)), with a second hash H2, provided H1 is not too broken.
• heynk 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?
  • 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...
      • 11y ago
• mizzao 11y ago
  Maybe another lesson is that security by obscurity is never going to work in this age. If someone steals your code, which is incredibly likely with the amount of digital infiltration happening constantly, your security mechanism still better be safe.
• redml 11y ago
  Hindsight is 20/20. Working on legacy software devs sometimes want to implement the proper solution on paper rather than the best one. Perhaps it was a task that the dev didn't get enough time to write something to update the passwords of a few million users. Perhaps they thought they'd come back to it in a few months and force a reset on users that hadn't switched their password yet. Who knows.
• iolothebard 11y ago
  How would it have been hard? Seems like a 10 minute fix at most to me to rehash the old password once the user was authenticated then put a flag whether they've been 'fixed' or not. After 3 months deactivate the old passwords and sent them an email reset. Although AM was in the business of essentially blackmailing their customers. So ease of getting back in was of higher priority apparently.
• onedev 11y ago
  I change my password once every half a decade probably
• Osiris 11y ago
  * MD5 of the bcrypted pass+username * How do you verify that? Since bcrypt generates a random salt when you hash a value, if you MD5 the resulting hash, you lose the salt. So, are they storing the bcrypt work factor and salt but doing an MD5 only on the hash portion? Seems like a needless extra step. Storing the bcrypt work factor, salt, and hash should be sufficiently secure. Unless you meant bcrypt(md5(pass+username)).
  • ecnahc515 11y ago
    Pretty sure they mean bcrypt(md5(pass+username)) since changing hashing algorithms is generally an additive change.
  • itslennysfault 11y ago
    There is no need to "verify" it was just a $loginkey used for automatic login. It's just a hash of: md5(lc($usename).”::”.lc($bcrypt-string)) They generate one and store it in the database and just do a basic string compare against the one used to auto-login.
• aaron695 11y ago
  What's the lesson here exactly? Lets say they spent the time redoing the passwords, would Ashley Madison be better off right now? This is a pimple on a elephant. And once you've killed the elephant it's kinda easy to find pimples. If anything this would have been a distraction from the real issues of however they actually got hacked. You might see it as a sign that they had bad security, but in hindsight it's all to easy to find signs.