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.

8 of 146 comments (clear)

  1. How it was done by sinij · · Score: 5, Informative
    TFA was uninformative. Instead, from http://cynosureprime.blogspot....:

    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.

    1. Re:How it was done by axlash · · Score: 5, Informative

      TFA was uninformative. Instead, from http://cynosureprime.blogspot....:

      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.

      Or this:

      http://arstechnica.com/securit...

      --
      Deal with reality - the world as it is - rather than ideality - the world as you would like it to be.
  2. Re:Programming error by GameboyRMH · · Score: 3, Informative

    Having the salt available would still mean that all the hashes would need to be reversed with rainbow tables or brute-forced. These being bcrypt hashes with a built-in salt, having any "extra" salt available would hardly help.

    Using the same salt for every hash is far less secure than having one for each hash too.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  3. More info by Okian+Warrior · · Score: 5, Informative

    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?

  4. Re:Programming error by turtle+graphics · · Score: 5, Informative
    The salt is stored with the encrypted password, in cleartext. When the user logs in, the system combines the password they typed with the salt it knows in order to get the key. The main thing salt does is to prevent people with the same password from ending up with the same key, so that everyone needs to be attacked individually. Here's what a bcrypt key looks like from the AM files:

    $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.

  5. Re:Programming error by dbraden · · Score: 3, Informative

    Ya, like sirber said above. In another story, they say:

    The source code led to an astounding discovery: included in the same database of formidable bcrypt hashes was a subset of 15.26 million passwords obscured using MD5

    and...

    "Instead of cracking the slow bcrypt$12$ hashes which is the hot topic at the moment, we took a more efficient approach and simply attacked the MD5 ... tokens instead."

    I thought I had seen a story about a problem with PHP's bcrypt implementaion not too long ago, but I can't find anything on it now so I might have misread something.

  6. Re:Programming error by sexconker · · Score: 1, Informative

    It's "password", for those wondering.

  7. Re:Programming error by buchner.johannes · · Score: 4, Informative

    But that was not the problem.
    They converted username & password to lowercase, and stored username, MD5("username::password") additionally to bcrypt2("username::password"). The MD5 hashes were resolved now, which is what this article is about. If they had not unnecessarily stored the MD5 hashes (probably a legacy field in the database, because only present for 11 of 36 million users), there would be no problem. Converting the password to lowercase was also unnecessary. The bcrypt2 passwords remain uncracked -- the remaining 25 million user entries still are secure as far as we can tell.

    Article here: http://arstechnica.com/securit...

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.