13 ms·
How we cracked millions of Ashley Madison passwords
- amelius 11y agoThe article assumes that the reader knows what MDXfind is. Can somebody explain? Is it a brute force tool?
- icebraining 11y agoFrom searching a little, it seems it's a hash cracker that can crack many types of hashes (MD5, SHA, etc) from the same file.
- amelius 11y agoOk, so it is a brute force tool, with some dictionary-based heuristics, I suppose.
- flipp3r 11y agotl;dr they had a bad implementation and used md5 previously
- ins0 11y agothey stored a static login key generated by md5(strtolower($username).'::'.strtolower($password)); - so they could crack the md5 part easly and bypass the bcrypt encryption
- novaleaf 11y agothanks for the writeup, that was the hunch from skimming the article but good to get confirmation!
- gvb 11y agoSlightly pedantic: "Discovery 1" email indicates that the $loginkey encryption was the weak md5 method until it was changed to bcrypt in a 2012-06-14 commit. As a result, any accounts that were created before 2012-06-24 and that did not have their password changed after that date (which would generate a new bcrypted $loginkey) were vulnerable.
- lostgame 11y agoI used to work for these guys. Their CEO was probably the single most selfish douchebag I'd ever met. Glad this happened to them. 'bout time Karma came a'knocking. Oh, p.s. can confirm all women (at least 90%) are bots.
- zeveb 11y ago> Their CEO was probably the single most selfish douchebag I'd ever met. He ran a website for men wishing to cheat on their wives. The one follows the other as night follows the day.
- rbanffy 11y agoDon't forget the bots wishing to cheat on their husbands.
- sparkystacey 11y agoHow many are bots overall?
- anc84 11y agoCreepy.
- chinathrow 11y agoI abandon any sites which give me direct logins via URLs sent over plain text emails. I know, password reset keys are as bad as login keys, but usually they expire after a certain time frame. F*ck login keys.
- asadhaider 11y agoCompletely agree, Match.com does the same thing. Not so long ago a user signed up to their site using my email address (never figured out why). They were able to create an account and subscribe to the site without ever verifying the email, so for a week or so I was getting notifications sent to me without any way to unsubscribe from the email. Clicking any of the links in the email signed me in as the user and gave me full access to their account and billing information. I ended up going into their account and turning off all email notifications to make the emails stop. Edit: Just checked my trash folder and an email sent on the 8th of August still contained valid login keys to access the account.
- hellofunk 11y agoThis is frightening. Who is running the security teams at these large companies?
- sbarre 11y agoYou'd be surprised how often this happens. I had a similar situation with someone who accidentally used my email when buying a new car. For a while I was getting emails from the Hyundai dealership that had auto-login links that would have let me do all kinds of things, including requesting a (paid) tow of the car from my house back to the dealership, scheduling (or cancelling) maintenance, ordering extras and part, and more.. Luckily through that logged-in area I was able to find the individual's phone number and we texted back and forth until he understood the problem and called his dealership to update his info.
- hellofunk 11y agoThis is genuinely amazing to me. And the IT guy that set up that Hyundai system is probably getting paid plenty to do it, despite massive flaws like this.
- nilved 11y agoWhat's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
- valarauca1 11y agoCould you recommend a good password manager?
- hattenn 11y agoTry LastPass.
- nilved 11y agoSelf-hosted: http://www.passwordstore.org http://www.passwordstore.org http://keepass.com http://keepass.com http://keepassx.org http://keepassx.org Paid: http://lastpass.com http://lastpass.com http://1password.com http://1password.com
- mr_sturd 11y agoI'll second nilved's suggestion of KeePass. The database is encrypted and stored on the local machine. I currently use Syncthing to share it between my devices.
- mikejarema 11y agoLikewise, I'm very happy with this exact setup after coming from a mix of memorized password and site-dependent password-generation schemes. I'm on Mac and found KeePassX to be a better solution than the original KeePass, it's much lighter weight. My only hope is that KeePassX gets browser integration at some point via keepasshttp - https://www.keepassx.org/dev/issues/91 https://www.keepassx.org/dev/issues/91
- mr_sturd 11y ago
- wbhart 11y agoThe domain name appears to be an anagram of Sony Pure Crime.
- aejdaoid 11y agoAlso Ryno Cise Murpe
- nathanasmith 11y agoCould be. Cynosure is also a noun denoting something that attracts attention through brilliance.
- nly 11y agoPony User Crime
- phaedryx 11y agoMore Nice Syrup Myopic Ensurer
- jand 11y agoFor a non-native speaker, could you please confirm or invalidate my understanding of this interesting text: 1. They attacked some login/api-token unrelated to bcrypt. 2. If I use bcrypt-validate for logins and only temporarily associate rotating, random login/api-tokens with an account, I should not be prone to such attacks. Thank you very much for your help.
- lostcolony 11y ago1. Yes 2. Yes AM took the unencrypted password, lowercased it, and hashed it into an MD5 token that they then stored - conjecture is that it was used as a login token. That is what the article indicates was cracked, since MD5 is very weak, to get a lowercased password, then tried every permutation of capital letters on the bcrypted passwords, to get the actual passwords out. To avoid similar issues, if you generate a token, don't use the unencrypted password as part of it. Random tokens are fine.
- nly 11y agoDon't worry. One day we'll have a standard for web login using hard hashes and solid PAKE protocols. Right? ...right? Nevermind then, let's go back to berating sysadmins for implementing crypto improperly.
- dsp1234 11y agoI recently found out that piwik also uses a login token of the MD5 of the password[0]. So this mistake is still very prevalent. If you want to provide a one-click automatic login to Piwik for your users, you can use the ‘logme’ mechanism, and pass their login & the md5 string of their password in the URL parameters: https://stats.example.org/index.php?module=Login&action=logme&login=your_login&password=your_MD5_password* https://stats.example.org/index.php?module=Login&action=logm... [0] - http://piwik.org/faq/how-to/#faq_30 http://piwik.org/faq/how-to/#faq_30
- notfoss 11y agoCan you open a feature request on their bug tracker to change it to a more secure alternative?
- etjossem 11y agoGood call. https://github.com/piwik/piwik/issues/8753 https://github.com/piwik/piwik/issues/8753 It seems like this has been on the back burner for a while, though ...
- acveilleux 11y agoThat's actually a whole lot worse than the AM version here. The MD5 hashes themselves are usable as valid password! And the cracking of the MD5 hash back to original password is fully amenable to rainbow tables. All you need is hashes which you can extract from DB or webserver logs... Or sslstrip'd/HTTP traffic if that's possible.
- snowwolf 11y agoThe title of the article should really be changed to "How we cracked millions of Ashley Madison passwords by bypassing their strong bcrypt hashes because they thought they were clever" but that's less clickbaity Also, never ever roll your own encryption - it will be flawed (unless you employ at least 3 crypto experts and get it peer reviewed - and even then it's probably still flawed).
- hardwaresofton 11y agoThey didn't really roll their own encryption right? They rolled their own session login stuff, used it for some sort of login-key (what I assume they passed with server sessions). Why they would do that instead of a simple session ID I will probably never know. Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers).
- snowwolf 11y agoThey generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.
- Someone1234 11y agoNo it isn't. That is a login routine/authentication. If they had replaced MD5/bcrypt with their own in-house alternative, that would be rolling their own "encryption" (hash function). But as is, they designed a login/authentication scheme that was highly flawed, but used off-the-shelf hash functions to do so (even if MD5 is deprecated at this point for anything security related). To phase this simply: "If they didn't do maths, they didn't design their own encryption scheme." They did not, so therefore they did not. Now you can argue the merits of using an off-the-shelf authentication/login scheme (e.g. Kerberos, OpenID, ASP.net's authentication provider, etc) and I would agree. But that isn't what you said, you specifically said they rolled their own "encryption" which they did not.
- 11y ago
- deleted 11y ago[deleted]
- aruggirello 11y agoOne point is not clear to me: did the crackers know $username's already, or did they perform some kind of dictionary attack? Brute forcing both $username and $password out of millions of hashes seems a bit hard - even considering md5 trivial, not employing an hmac scheme.
- felixhandte 11y agoThey have the db dumps, so yes, they know the usernames. And they used a rainbow table[1] to break the md5 hashes, which is a lot cheaper than brute-forcing. [1] (https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table)
- aruggirello 11y agoThen would replacing md5() with hash_hmac('sha256' [= or whatever ], strtolower($username) [= data ], strtolower($password) [= key ] ) help against such an attack? If I understand correctly, this would have ruled out rainbow tables. Edit: clarified. BTW hash_hmac is built-in with PHP >= 5.1.2.
- sbov 11y agoThe problem isn't just rainbow tables. Md5 is a fast algorithm. Sha256 isn't much slower than md5. You want anything auth related hashed using a slow algorithm - speed is your enemy. That's why bcrypt and the like are popular, because you can adjust how long it will take to calculate.
- tempVariable 11y agoLike protecting your business with an industrial grade door locks on a building made of hay. Just a whole lot of cheating going on over there, ouch. edit: I don't know if this came up before, but based on how they stupidly tried to cache the login session tokens with md5, instead of running through the 12 work factor bcrypt, I can assume that they saw this as a bottleneck. Instead of dropping the work factor or doing this caching baloney, could a service be made that runs on extravagantly fast hardware, which provides an API for strong, high work factor bcrypt, pbkdf2 based authentication. I can assume that at around 10 rounds, each attempt takes about 50 - 100 millis Thoughts ?
- stan_rogers 11y agoThe "remember me" token doesn't need to contain or be derived from any meaningful data at all; it merely needs to be unique to the user so you can associate it with the user, and should be both unpredictable and frequently changed/regenerated. It's just a more persistent version of the session ID you'd be using in any case even if the "remember me" option wasn't selected.
- djrogers 11y agoThe 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 ago they fixed it. They switched from an MD5 of lower(pass)+username to an MD5 of the bcrypted pass+username, which is no longer reversible. Apparently they never updated all of the previous login tokens though, so anyone who had created an account before the new secure system was put in place still had a vulnerable token stored. When it comes to security, when you fix something - fix it for everyone people! Even if it's hard. The good news for these folks is that the passwords revealed appear to be over 3 years old, and we all chang our passwords more often than that, right????
- artursapek 11y agoUpdating 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 agoAs 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 agoI 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
- sparkystacey 11y agoIt would be awesome if some data scientist took the list of passwords and figured out the top 100 for cheaters.
- grandalf 11y ago> This meant that we could crack accounts created prior to this date with simple salted MD5. This means that there was a decision not to force previously created accounts to update their passwords to make their accounts more secure. Contrast this with the big Evernote vulnerability where all users were required to reset their passwords.