Slashdot Mirror
Ashley Madison's Passwords Cracked, Soon To Be Released
New submitter JustAnotherOldGuy writes with some news that might worry anyone caught up in the Ashley Madison data breach. ("Uh-oh," he says.) Now, besides any other possible repercussions of having one's name on the list of account holders, there's a new wrinkle. The passwords used to secure those accounts were theoretically robustly protected with bcrypt. However, as Ars Technica reports,
That assurance was shattered with the discovery of the programming error disclosed by a group calling itself CynoSure Prime. Members have already exploited the weakness to crack more than 11 million Ashley Madison user passwords, and they hope to tackle another four million in the next week or two.
This would matter much less if passwords weren't so frequently re-used.
Damn! They cracked my password already.
Have gnu, will travel.
Instead of cracking the slow bcrypt hashes directly, which is the hot topic at the moment, we took a more efficient approach and simply attacked the md5(lc($username).”::”.lc($pass)) and md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”) tokens instead. Having cracked the token, we simply then had to case correct it against its bcrypt counterpart.
The Ashley Madison system stored an MD5 hash of the lower-cased username and password on the user's computer, so that they could revisit the site without having to reenter their login info.
Computing MD5 hash values is much faster than computing bcrypt() values, the hackers already had the username, and both fields were lower-cased.
They just brute forced the MD5 hash until they got a match. About 90% of the MD5 passwords matched exactly (ie - the passwords were already in lower case), of the remaining 10% they tried uppercasing the individual letters of the password until it matched.
Security is hard. Basing the MD5 hash on a reduced-space plaintext password was the fundamental error.
Also there were some administrative lapses. They changed password hash algorithms, and then forced users to change passwords at next login. Many users hadn't logged in in several years, so this left a lot of old, insecurely hashed passwords around.
Generally poor security for such a sensitive site. Makes me wonder how good other popular sites are at security.
We really should figure out this security thing.
Perhaps an open-source fixed-function password keeper (as Mooltipass) in separate trustable hardware would work?
$2a$12$p9Ctp8EvU1x9jc09dqslHeGxS/Ytu464Xs5Yn1/AkqMSqAAN.4coa
The salt is p9Ctp8EvU1x9jc09dqslHe, the 22 characters that follow the $2a$12$. If you want to crack this password, make a guess, use bcrypt to combine it with that salt, and if they match you've cracked this password. This one is not hard to guess.
It still gets me.
You run a huge operation, with thousands of users and millions of dollars flowing through it.
At which point do you need to stop and think "Actually, I need a server that does NOTHING but authentication, isolated from everything else?"
Literally a machine that can only communicate Yes or No and maybe a tiny token and every communication to it can only be replied to by yes, no, or issue of a temporary token (which can only be verified by the same machine answering yes or no).
Changing passwords is a rare, deliberate, easy-to-audit and unusual act - you could literally have a guy who has to press a button to okay each such action. Apart from that, an application has absolutely no need to do anything more than pass on info to a server that can reply yes or no. Whether that's from a initial password login, or checking a temporary token issued, that's all it needs to do.
It's not the be-all-and-end-all - you can compromise the interface and wait for a user to log on and thus capture a successful transaction - but this outright theft of every login detail and a list of things that, given time, can be turned back into passwords shouldn't be happening, should it?
I mean, quite literally, a serial cable should be able to handle such information on the scale of a half-decent sized website. Is this user 1's password? No. This is what user 2 claims his password is, can I get a token for that valid for the next hour? Is this token valid for user 2? What more beyond that do you need to program against to authenticate absolutely anything imaginable?
And even password updates - they operate on the same principle as the way that admins cannot see their user's passwords. We can update them, but we can't actually see what they were and the very act of updating them locks out (and therefore alerts) the genuine user.
Isolate this stuff. Seriously. An entire network that is air-gapped from your real network and literally the applications either side can ONLY communicate over a protocol that contains the bare minimum of commands. You could do it with an embedded device. Why are places with millions of dollars of business storing anything on a device that can be read back en-masse by even their own staff, let alone a compromised machine on the company's office network or similar?