back to article Cracktivists pop 11 MEELLION Ashley Madison passwords

It has been claimed that 11 million of the leaked passwords contained in the Ashley Madison data dumps have been cracked by a group of researchers operating under the name "CynoSure Prime". The cracking lays waste to Ashley Madison's remaining security street credibility, as the disgraced site used the lauded bcrypt …

  1. Ralph B


    I suppose I can kinda see the motivation from a "mental masturbation" point-of-view, but, really, can't they find something more useful and/or creative to do with their time and intelligence?

    I mean the "crackivists", the sleazy website operators, and the sleazy website's customers, the lot of them. Go and do something positive for humanity, FFS.

    (And I don't mean go and shine laser pointers at self-driving cars either. Jeez, you guys!)

    1. Elmer Phud

      Re: Point?

      When the sleazy operators and equally sleazy 'customers' of this pimp shop seem more concerned about thier security than cheating on partners - I reckon the hackers (if they did actually 'hack' and not just used already available tools) have done us a favour.

      11 meeeelion people who are to be kept at the end of someone elses barge pole have been identified.

    2. Anonymous Coward
      Anonymous Coward

      Re: Point?

      I suppose I can kinda see the motivation from a "mental masturbation" point-of-view, but, really, can't they find something more useful and/or creative to do with their time and intelligence?

      But really this is useful and creative. A website was hacked, so natural human curiosity is to ask how it happened. Which leads to thoroughly reverse engineering the whole thing and finding all the weaknesses.

      Hopefully - in time - lessons get learned and security improves. Darwin and all that.

  2. David Roberts

    Two factor security?

    We've encrypted this password (insecurely stored here) in a secure store.

    Does make you wonder about all the other sites who think they have strong security. Did they use a standard package, and if so which one?

    Kudos to the researchers. Shows that you need to do more than just use a secure password store; the whole end to end process needs to be audited with a fine tooth comb.

    1. Michael Wojcik Silver badge

      Re: Two factor security?

      We've encrypted this password (insecurely stored here) in a secure store.

      If the details in the story are correct, AM wasn't storing an encrypted version of the password anywhere.

      What they were storing is two separate password verifiers, both of which were cryptographic hashes of either the password or a string that included the password folded to lowercase. And in one of those cases, the work factor for attackers1 is greatly reduced.

      (Also "secure" and "insecure" aren't very useful, since they're only meaningful as relative measures under a threat model.)

      1For attackers with access to certain resources, that is. Those resources are readily available under common circumstances.

    2. leexgx

      Re: Two factor security?

      this is what happens when you roll your own security and you think you know better

      if they had no hashed the password twice one with very time consuming one that takes the guessing down to about 150 guess a second per GPU (witch is good) but they also for some dumb reason to a MD5 one that allows you to do over billions as they converted all upper cases into lower so they only needed to do abc123 not AbC123 and then quickly compare it to the bcrypt hash to confirm them (they have to do some variations like Cat1 cat1 cAt1 caT1 until they got a hash match, typically the first one matchs as most passwords start with a Capital letter if your forced to have one upper case and a number)

  3. Spender

    How many developers get this wrong?

    A simple check of reveals that there's a huge reluctance among developers to accept security best practices.

    That's 730 pages of results. Ouch.

    This problem has been solved in almost every credible web-platform by off-the-shelf, well tested login systems... yet a certain, highly prevalent breed of developer always thinks they can do better.

    Sadly, the issue of security is very poorly understood by tiers of middle-management who allow these idiots to carry on breaking the web.

  4. A Non e-mouse Silver badge

    Poor article

    This El Reg article is quite poor and confusing. A much better article (with a bit more meat to it, so to speak) is over at Ars Technica.

    TL;DR summary: The passwords were stored twice: Once with bcrypt encryption, and a second time with weakened MD5 encryption. The crackers have cracked the MD5 passwords. Not all accounts appear to have the MD5 version of the password.

    1. TheVogon

      Re: Poor article

      "Not all accounts appear to have the MD5 version of the password."

      Presumably those that have never logged in externally. Such as fake accounts generated from within Ashley Madison itself for instance.

    2. Vic

      Re: Poor article

      The passwords were stored twice: Once with bcrypt encryption, and a second time with weakened MD5 encryption.

      I'm glad you posted that. That was what I got from the article - then I thought "no-one could be that stupid, could they?" and ended up in a flat spin trying to work out what was meant...


    3. Charles 9 Silver badge

      Re: Poor article

      Given that MD5 is a one-way hashing algorithm, not an encryption algorithm, perhaps someone can enlighten us how figuring out a password to match the MD5 allows them to figure out the bcrypt-encoded password.

      1. John H Woods Silver badge

        Re: Poor article

        My understanding is this:

        They effectively stored what amounted to the MD5 hashes of the passwords AS WELL as the bcrypt ones.

        Brcypt$12$, applies 2^12 (4096) rounds of hashing. This should make the leaked bcrypt passwords very expensive to crack, and that's why AM said the passwords were safe. HOWEVER, there were also "tokens" of some sort, represented by the MD5 hashes of (prior to about June 2014) a concatenation of the lowercased username, lowercased password and the salt string. The salt and usernames being known, very many guesses could be made at the password: you just run through a list of lowercase passwords, inserting them into the input and, because MD5 is so fast (unlike bcrypt) very many guesses of these can be made in a short space of time. When you get a collision, you know what the lowercase of the password is. So then you just have to try all that password in every possible case combination and (especially as many of the passwords had low numbers of capitals -- many had none -- this is not that hard) run those through bcrypt$12$ to find out what the password was.

        1. John H Woods Silver badge

          Re: Poor article

          Sorry that's a bit garbled, I'm not well at the moment. Say you have a dictionary including common passwords. You then get access to the a set of bcrypt12 hashes and the salt . You can now begin to check for passwords - you add the salt to each password in your dictionary and run it through bcrypt12. Problem - that is a slow algorithm (on purpose). However, AM had also stored the MD5s of some tokens they had foolishly made (I may be simplifying a bit) by concatenating together lowercase usernames, passwords and a salt. "johnhwoods::password123::salt". Now, MD5 is fast, and you know the usernames and the salt, so you can very quickly look for collisions. If you find that password123 gives you a collision, you know that some case variant of it is the answer. So now, you only need to check 256 case variants: you'd probably start "as is" then the 8 combinations with one capital, then the 28 with two etc. Suddenly instead of needing to run your whole dictionary through bcrypt you just have a few variations.

  5. jake Silver badge

    Is the term the newly invented "popped" ...

    ... Or is it the long-term acknowledged "cracked"?

    Inquiring minds want to know.

  6. Anonymous Coward
    Anonymous Coward

    MD5 insecure?

    The article is somewhat misleading: AM's mistake wasn't their use of the "insecure" MD5 hash function. If they'd done what they did but replacing MD5 with one of the recommended, more "secure" replacements for MD5, such as SHA-256, then they would have had no significant increase in security. The problem was what they did, not the precise choice of hash function for doing it.

    By the way, passwords were not "stored" with "weakened MD5 encryption". MD5 is a hash function, not a cypher. You don't "encrypt" things with MD5. Bcrypt isn't a cypher, either; it's basically a specialised hash function.

  7. arshadnoor

    Application developers playing with fire

    Unless an developer's full-time job revolves around cryptography, general-purpose application developers should NOT be making crypto-decisions. They don't spend enough time with crypto to understand risks in their design-choices.

    Fortunately, for the post Ashley Madison developers, there is a better way: eliminate passwords altogether using <a href="">FIDO Alliance's</a> U2F protocol. With open-source <a href="">U2F servers</a> and $5 FIDO Authenticators that customers can buy on <a href="">eBay</a>, websites and consumers can now protect themselves with strong-authentication. Even if bad application designs fail them, at least no passwords will be breached.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021