How we cracked millions of Ashley Madison passwords

http://cynosureprime.blogspot.com/2015/09/how-we-cracked-millions-of-ashley.html

by ctz • 11 years ago

372 166 11 years ago

cynosureprime.blogspot.com

flipp3r• 11 years ago

tl;dr they had a bad implementation and used md5 previously

ins0• 11 years ago

they 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• 11 years ago

thanks for the writeup, that was the hunch from skimming the article but good to get confirmation!

gvb• 11 years ago

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

anc84• 11 years ago

Creepy.

chinathrow• 11 years ago

I 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• 11 years ago

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

hellofunk4• 11 years ago

This is frightening. Who is running the security teams at these large companies?

davidshepherd7• 11 years ago

I had the same thing, but I was unable to even log in and stop the emails. I had to just mark it all as spam in the end.

KMag3• 11 years ago

Not so long ago a user signed up to their site using my email address (never figured out why).

If they used legit billing information, with a name other than yours, it was probably a legitimate typo of the email address while signing up, using copy-paste to avoid typing the email address a second time. They probably haven't yet realized they aren't getting emails for their account.

Someone (or two people with the same name) has signed up for a Hertz car rental account and a trash removal service account using a name that could reasonably be mapped to my gmail username. I presume they either have <my_username><2/year/other_number>@gmail.com or <my_username>@<some_other_provider>.

m0v_eax• 11 years ago

Some applications do not store any sensitive information, in which case login keys are not so bad..

nilved3• 11 years ago

What'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• 11 years ago

Could you recommend a good password manager?

hattenn• 11 years ago

Try LastPass.

nilved3• 11 years ago

Self-hosted: http://www.passwordstore.org http://keepass.com http://keepassx.org

Paid: http://lastpass.com http://1password.com

mr_sturd2• 11 years ago

I'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.

yrro• 11 years ago

I use https://github.com/jamessan/vim-gnupg

brusch64• 11 years ago

I like KeePass and use it daily.

zeveb2• 11 years ago

I like Password Safe (https://www.schneier.com/passsafe.html), although I do wish that it used AES-256, SHA-384 &c.

sillysaurus32• 11 years ago

Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.

JosephRedfern4• 11 years ago

I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway?

(edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already have access to the data that knowing the password behind the hash would provide).

kijin2• 11 years ago

Long, random password stored in plaintext: as soon as the user database is compromised, the attacker can log into your account and do whatever they want. This may result in additional exposure of information that wasn't part of the original compromise. The attacker can also impersonate you and cause other kinds of damage.

Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the attacker gets the user database and nothing else.

nilved3• 11 years ago

Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.

stephenr• 11 years ago

If I breach your environment and get access to bcrypt hashes, they are useless to me as-is.

If I have enough processing power to brute-force compare them, I can eventually get the original password back, but that isn't a zero-cost effort in terms of time. As soon as you realise you have been breached, I would expect you would have initiated a lockdown of some kind, either preventing access to accounts until the owner can confirm identity, or forcing a password reset for all users.

If you store passwords in plaintext, I can copy the passwords, and impersonate users even while they continue using their accounts, unknown to them.

steckerbrett2• 11 years ago

If you have the computing power? If you're compromising peoples boxes you likely also have a botnet, which has practically limitless potential.

throwaway2048• 11 years ago

that is a ridiculous assumption that only leads to really silly "if the 8 planets are aligned just so" kind of justifications that make people feel fine with awful security practices.

lostcolony3• 11 years ago

Let's also assume that any given server will never be hacked. It's more realistic.

ddlatham2• 11 years ago

While uncommon, it's not ridiculous. A site could, for example, decide to generate a user's password rather than allow them to provide their own, thus guaranteeing it be long, random, and unique. However, it's still not a good idea to store such passwords in plaintext.

patio11• 11 years ago

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords?

This assumption is known to be false. We should not design systems around this assumption. If we do, popping a random startup will give up Gmail accounts, by the thousands to tens of thousands, and since we've settled on email accounts as The One Ring To Your Identity that imperils their brokerages, domain registrars, employers, World of Warcraft characters, physical safety, privacy, cat photos, etc.

wbhart• 11 years ago

The domain name appears to be an anagram of Sony Pure Crime.

aejdaoid• 11 years ago

Also Ryno Cise Murpe

nathanasmith• 11 years ago

Could be. Cynosure is also a noun denoting something that attracts attention through brilliance.

nly2• 11 years ago

Pony User Crime

phaedryx• 11 years ago

More Nice Syrup

Myopic Ensurer

jand2• 11 years ago

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

lostcolony3• 11 years ago

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

jand2• 11 years ago

I cannot upvote yet, so: Thank you, I appreciate your help!

user_0001• 11 years ago

lol.

Store a strongly hashed copy of the password, but use weak hash on password for login token. oops

nly2• 11 years ago

Don'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• 11 years ago

I 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=logm...

[0] http://piwik.org/faq/how-to/#faq_30

Reply

notfoss• 11 years ago

Can you open a feature request on their bug tracker to change it to a more secure alternative?

Reply

etjossem• 11 years ago

Good call. https://github.com/piwik/piwik/issues/8753

It seems like this has been on the back burner for a while, though ...

Reply

acveilleux• 11 years ago

That'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.

Reply

snowwolf3• 11 years ago

The 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).

Reply

hardwaresofton3• 11 years ago

They 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).

Reply

snowwolf3• 11 years ago

They generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.

Reply

pygy_6• 11 years ago

Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers).

Since at some point the loginkey was based on the unencrypted password that means that they either had to store the PW in clear (and fetch them from the DB) or generate the key at account creation and fetch it from the DB anyway.

A good strategy to check the token validity without reaching the DB is to sign it cryptographically. The loginKey can be $randomString+sign($randomString). The endpoint can check the signature before doing more costly things like a network request.

Reply

hellbanner• 11 years ago

I understand "never roll your own encryption" -- history is full of examples why and we all know that encryption is hard.

But who makes encryption in the first place -- groups?

Reply

chetanahuja• 11 years ago

and those crypto experts? They usually spring fully formed from the head of Zeus.

Reply

pygy_6• 11 years ago

Yup, groups of expert mathematicians, also known as "cryptographers". They create and review on another's schemes.

The author of a scheme can be a single competent person, but it would be unwise to trust it before peer review, regardless of the author's track record.

Reply

rnovak5• 11 years ago

There's a US Govt agency called NIST. They sponsor "contests" basically for academics and engineers to put forth proposals for crypto algorithms, which are then reviewed. I'd read up on here[1], if it interests you at all, you can find the original academic papers regarding each of what became the standards, and I think they have references as to the review process as well.

[1]http://csrc.nist.gov/

Reply

saalweachter• 11 years ago

The short answer is "don't be a dilettante".

If you want to do crypto, you have to do crypto. You can't just code up an algorithm one weekend and use it for the rest of your life (or the rest of your business's short life). You have to code up a bunch of algorithms, read a bunch of other people's implementations, learn the strengths and weaknesses of different techniques, follow the trade literature, go to conferences, argue with other cryptographers over beers. Be plugged into the sorts of networks which will let you know when your favorite crypto technique is starting to become weak.

It's fine to have a diverse set of interests, try your hand at various things. But some things you have to really commit to. You can get away with half-assing a lot of things, but some things -- like cryptography -- need to be fully-assed.

Reply

sctb• 11 years ago

We updated the title to something less misleading.

Reply

rnovak5• 11 years ago

This should be extended to "Never roll your own security", because that's really the crux. As many, many people have pointed out in the past, that's why books like Modern Cryptography exist. In these books, they basically say "hey, use these functions and these parameters, and you probably wont die", but in this case, ALM said "screw those parameters, we're smarter than you!!!!" and rolled their own security. As noted by the article, bad move.

Reply

jszymborski2• 11 years ago

but that's less clickbaity

They cracked millions of AM passwords. That's not an exaggerating, but the fact of the matter.... since when to titles need to be tl;dr's

Reply

snowwolf3• 11 years ago

They did actually change the title [1] - It was misleading before, and in fact the heading of the article still is - "How we cracked millions of Ashley Madison bcrypt hashes efficiently" - impliying they are able to crack bcrypt efficiently (they can't).

[1] https://news.ycombinator.com/item?id=10198351

Reply

compbio• 11 years ago

I understand the meme: "Never ever roll your own encryption", but I am stubborn enough to ask: "Why?".

Why use bcrypt over scrypt over pbkdf2? Because crypto experts told you? How could you know it is correct, if you are not able to inspect it? By the amount of people yelling "Use bcrypt"?

I know that in crypto you should expect an attacker to be able to read your source code. If you can keep secrets, while your source is out in the open, then it is good crypto. But does that mean you do not need a script-based salt? An attacker which can get into your database, should be able to get code-read access too right? I don't think so... Databases are leaked on forums without any trace of the source code/app logic. When these people did not roll their own encryption, any attack which is able to beat modern crypto (you will never hear of this, as you are not an expert), could now attack you. They fingerprint the hashes, try to find out which expert roll you used, open their suitcase of crypto breaking tools written by the same expert when she was working for the NSA, under cover of doing a PhD at MIT, and go to town.

Don't listen to me, because I am not an crypto authority, but do roll your own encryption: Give your own twist to it. That is security by obfuscation, and would not put all eggs in the same basket. An attacker has to be able to break your custom scheme now, for every different site/database attacked. It could be simple, it could be near perfect, but it won't be as simple as pressing a button on the "break modern crypto"-toolkits.

If you are one of the few doing this: People will move to less arcane targets in the never-roll-your-own-basket. If you are one of the many doing this, breaking crypto would become an unmanageable field of eggs.

If I was a state actor in charge of keeping secrets and breaking crypto, these two memes: "Never roll your own encryption" and "just use bcrypt" are exactly the memes I would propagate to the tech crowd. Even moreso when you can already break bcrypt (or expect to in 5 years and just store everything that looks encrypted with bcrypt) and want to keep your task manageable.

AM would be harder to crack if they'd ROT-13'd the hashes in the source code.

Reply

hardwaresofton3• 11 years ago

no no no no no no no no please no.

There are well documented reasons to use bcrypt/scrypt/etc over things like MD5/SHA1/SHA2. It's mainly a problem of hashing speed. It is also not impossible to understand how these algorithms work (and understand why they are more safe/take more time). If your password hashes are dumped, it's a question of time before they're decrypted. Depending on the algorithm you use, that time can either be minutes/hours, or it can be days/months/an infeasible amount of time.

You are correct that the implicit chain of trust around why you should use those things should not be free of suspicion, but that is a terrible reason to not use state-of-the-art techniques.

Modern crypto is demonstrably hard to crack because of mathematics. The question of whether it is all broken is there, but it's much harder to break/cheat mathematics than anything else (and again, proofs exist to prove stuff).

DO NOT build your own encryption, or put your own "twist" on any existing well-known methods. What you think is clever might take an attacker 10 minutes to figure out. Take a small pill of humility, you're not as smart or original as you think you are.

There is no "break modern crypto" toolkit. Most toolkits that script kiddies use are around broken APPLICATION of security intense. Assuming RSA/AES are not broken, then only theorized attacks require quantum computers. In 2015, it is highly unlikely that your adversary will have quantum computers, unless they are the NSA, and then your problems are much bigger than that (ex. if you interact with any company in the US, you are hosed). The overwhelming majority of businesses are compromised from things like phishing or running (discoverably) outdated software on their servers (ex. Some super old version of tomcat with known vulnerabilities, that announces itself in the HTTP header).

If you have information crackers want, your little security scheme will get owned. It is better to put your trust in proven/provable mathematics, even if you are not an expert. Arguably, your adversary is the kind of person that ENJOYS solving puzzles. Adding one more puzzle is not going to turn them away, it's going to make it even more fun.

When you have a sufficiently bad injury/infection, you don't go try and work up your own remedy, you go to a doctor. The fact that you didn't go to medical school and may not necessarily trust your doctor doesn't make it a good idea to start making up remedies for issues that have been well-studied by others.

Reply

hueving• 11 years ago

When you do that you end up losing entropy or leaking information. Just because you have no idea what you are doing doesn't mean than it won't be trivial for someone else to recognize and exploit.

The amount of people telling you to use bcrypt has nothing to do with it. It's the peer review conducted by hundreds of experts that understand information theory that is the indicator. Crypto experts aren't just randomly shifting around bytes and hoping it works, modern protocols all protect against various attacks that you are going to expose yourself to by ignoring them.

Even if you're not an expert, you will immediately hear of any attack on modern crypto because it will be a huge deal. These are algorithms the NSA recommends to other arms of the US government that they are protecting.

If the attack is not made public, you will be screwed anyway if you are a target because all of your OS update mechanisms (package signing, etc) all depend on modern crypto so an attacker with the ability to break that will see your super secret hash function of "count the 1s" anyway.

Reply

aruggirello2• 11 years ago

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

Reply

felixhandte• 11 years ago

They 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)

Reply

aruggirello2• 11 years ago

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

Reply

lostgame• 11 years ago

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

Reply

zeveb2• 11 years 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.

Reply

rbanffy• 11 years ago

Don't forget the bots wishing to cheat on their husbands.

Reply

sparkystacey2• 11 years ago

How many are bots overall?

Reply

amelius2• 11 years ago

The article assumes that the reader knows what MDXfind is. Can somebody explain? Is it a brute force tool?

Reply

icebraining2• 11 years ago

From searching a little, it seems it's a hash cracker that can crack many types of hashes (MD5, SHA, etc) from the same file.

Reply

amelius2• 11 years ago

Ok, so it is a brute force tool, with some dictionary-based heuristics, I suppose.

Reply

tempVariable2• 11 years ago

Like 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 ?

Reply

stan_rogers• 11 years ago

The "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.

Reply

djrogers• 11 years ago

The 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????

Reply

artursapek3• 11 years ago

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

Reply

tempVariable2• 11 years ago

As 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

Reply

cruise02• 11 years ago

It's possible to update everyone's password without them logging in. If the old storage was just MD5(password) and you want to update it to MD5(bcrypt(password)), you're out of luck. You need the plaintext password to make that change. If instead you change your new storage to MD5(bcrypt(MD5(password))), you can take all of the hashes currently in your database and update them at one time with MD5(bcrypt(old hash value)).

Reply

jandrese• 11 years ago

The proper solution would have been to flag the old passwords and require everyone to change them on the next login. After a couple of months you null out the remaining passwords and require anybody coming back to go through the password reset system.

Reply

yk• 11 years ago

Depends, if your old hash is H1, then you can migrate to a scheme H2(H1(password)), with a second hash H2, provided H1 is not too broken.

Reply

heynk• 11 years ago

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

Reply

gizmo686• 11 years ago

You could delete the old hash and require users to generate a new one through the password reset mechanism. Generally you would want to combine both approaches, so that only users who do not log in during the transfer window have to deal with setting a new password.

Reply

thedz• 11 years ago

This wasn't the PW hashing fucntion. The new method hashes using the bcrypt of the password, which they do have.

Reply

encoderer• 11 years ago

No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.

Reply

syncsynchalt• 11 years ago

No, you can re-hash the original hash you have, and add an additional check at login for new-hash(original-hash(password)).

Reply

msbarnett3• 11 years ago

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

No. Well, I mean, it's common to do that, but it's a bad idea and it's not necessary to keep all of those vulnerable hashes around.

Say you have a bunch of MD5 password hashes stored, and you want to upgrade your password hashing to BCrypt. Don't wait for the user to login and rehash their plain text password.

Instead, Bcrypt all the MD5s. The authentication mechanism is now BCrypt(MD5(plaintext)) == stored_bcrypt. Upgrade them to straight bcrypt on login.

Reply

knodi123• 11 years ago

that's the only time you have the PW in plain text

Well, if the issue is that your hash is crackable.... ;-)

Reply

mizzao• 11 years ago

Maybe another lesson is that security by obscurity is never going to work in this age. If someone steals your code, which is incredibly likely with the amount of digital infiltration happening constantly, your security mechanism still better be safe.

Reply

redml• 11 years ago

Hindsight is 20/20. Working on legacy software devs sometimes want to implement the proper solution on paper rather than the best one. Perhaps it was a task that the dev didn't get enough time to write something to update the passwords of a few million users. Perhaps they thought they'd come back to it in a few months and force a reset on users that hadn't switched their password yet. Who knows.

Reply

iolothebard• 11 years ago

How would it have been hard?

Seems like a 10 minute fix at most to me to rehash the old password once the user was authenticated then put a flag whether they've been 'fixed' or not. After 3 months deactivate the old passwords and sent them an email reset.

Although AM was in the business of essentially blackmailing their customers. So ease of getting back in was of higher priority apparently.

Reply

onedev• 11 years ago

I change my password once every half a decade probably

Reply

Osiris• 11 years ago

* MD5 of the bcrypted pass+username *

How do you verify that? Since bcrypt generates a random salt when you hash a value, if you MD5 the resulting hash, you lose the salt. So, are they storing the bcrypt work factor and salt but doing an MD5 only on the hash portion? Seems like a needless extra step. Storing the bcrypt work factor, salt, and hash should be sufficiently secure.

Unless you meant bcrypt(md5(pass+username)).

Reply

ecnahc515• 11 years ago

Pretty sure they mean bcrypt(md5(pass+username)) since changing hashing algorithms is generally an additive change.

Reply

itslennysfault• 11 years ago

There is no need to "verify" it was just a $loginkey used for automatic login. It's just a hash of: md5(lc($usename).”::”.lc($bcrypt-string))

They generate one and store it in the database and just do a basic string compare against the one used to auto-login.

Reply

aaron695• 11 years ago

What's the lesson here exactly?

Lets say they spent the time redoing the passwords, would Ashley Madison be better off right now?

This is a pimple on a elephant. And once you've killed the elephant it's kinda easy to find pimples.

If anything this would have been a distraction from the real issues of however they actually got hacked.

You might see it as a sign that they had bad security, but in hindsight it's all to easy to find signs.

Reply

sparkystacey2• 11 years ago

It would be awesome if some data scientist took the list of passwords and figured out the top 100 for cheaters.

Reply

grandalf• 11 years 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.

Reply

How we cracked millions of Ashley Madison passwords

Related Stories