4

According to this site Ashley Madison was keeping an insecure hash stored in their database using MD5, in addition to the far more secure bcrypt hash. This group used the MD5 hashes to quickly crack the password database rather than use the far more difficult to crack bcrypt hashes.

The article only gives this brief clue:

The $loginkey variable seemed to be used for automatic login, but we didn’t spend much time investigating further. It was generated upon user account creation and was re-generated when the user modified their account details including username, password and email address.

The question is, what's the purpose of this $loginkey variable? It's obviously pointless to use bcrypt which is purposefully slow when you're using a far, far faster hash like md5 elsewhere that's an easier target. Obviously this is a large blunder on the part of the Ashley Madison developers, but I'm curious as to why they would have put this in in the first place, and why it was never fixed since (someone) knew to use bcrypt for the main password hash.

Improve this question
  • 1
    would have to look at the source code to see what they used it for – schroeder♦ Sep 10 '15 at 19:19
  • It seems probable that several developers contributed to the site code, one who knew what bcrypt was about, and another one who did not. – Tom Leek Sep 10 '15 at 19:47
  • @TomLeek Almost certainly true. It points to a culture where one hand creates a problem, another hand fixes it, and a 3rd hand creates it all over again. Also, there's another iteration of the $LoginKey where they use md5(bcryptHash), which doesn't suffer from the vulnerability. So someone at some point realized the blunder, but never fixed the majority of the bad hashes, or simply just removed whatever the feature it was supporting. – Steve Sether Sep 10 '15 at 20:06
3

Probably as a token for users to login (i.e. "Remember my login").

If you want users to be able to use remembered login functionality, then you need to use a crytographically secure pseudo random number generator (CSPRNG) to generate the token. Then calculate an expiration date for that token to be used, and store both the token and the expiration date in your database. Once the user logs in (and indicated at login that they wanted to remember their login) you would store the plain text of the token on their machine in the form of a cookie or local storage. Then next time they tried to access a page which required a login, you would search for that token in their browser's cookie or local storage. If the token matches with a token that you stored in your database, and if the expiration date for that token is still in the future, then consider the user to be logged in; delete the token from their browser as well as the database, and repeat the process of generating and storing a new token all over again.

For added security, in your database you probably want to store the hash of the token rather than the token itself. As long as you used a CSPRNG to generate the token, you should be able to use even a fast hashing algorithm to hash the token.

I think the Ashley Madison devs simply didn't use a CSPRNG to create the $loginkey and instead used a non-random sequence of characters (username plus the MD5 hash of the password), which currently is what made it so easy for crackers to determine the unhashed portion of the $loginkey, which in this case was the password.

Improve this answer
0

The coverage at Ars Technica has a good discussion in the comments. http://arstechnica.com/security/2015/09/once-seen-as-bulletproof-11-million-ashley-madison-passwords-already-cracked/

Some speculation:

  • A legacy hash. At some point the devs switched to bcrypt but kept the old hash around "just in case".
  • $loginkey was used to login faster (bcrypt is slow by design) or keep a user logged in.
  • Used to keep a user logged in across other applications. Like on a forum platform that couldn't do bcrypt.
Improve this answer
  • 3
    It seems that they protected passwords with bcrypt if you updated your password after 2012-06-14 so I'm not sure that your first or second bullets are incorrect. – Neil Smithline Sep 10 '15 at 20:33
  • @NeilSmithline it would be completely consistent with standard Developer practices to continue hashing the password both ways for some period after the introduction of bcrypt, so point 1 may not just reference keeping actual hashed passwords around but also hashing new ones with the old algorithm as well as the new algorithm. (Which is why Security people hate Developers, in general) – gowenfawr Sep 11 '15 at 12:19
  • But we know that wasn't the case. Search for "2012-06-14" in the link in my previous comment. We know that on that date, with commit 1c833ec7, they went to storing passwords with bcrypt and $loginkey as MD5 of bcrypted password. – Neil Smithline Sep 11 '15 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.