How we cracked millions of Ashley Madison passwords
cynosureprime.blogspot.com
cynosureprime.blogspot.com
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????
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.
Well, obviously. For instance, it lacks the property of being trivially vulnerable to a GPU hashing the entire dictionary with a given salt in 30 seconds flat.
This also makes generating test data easier, as our library has a "plaintext" hash type, so we can just insert "$plaintext$password" rather than having to run a hash on the password.
edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...
The entropy isn't the significant problem with MD5. The problem is how damn fast you can perform 2 billion MD5 hashes on modern machines.
1: Vulnerability to a pre-computed table. This hits hard if you are using plain-old MD5 without a salt.
2: Vulnerability to a newly computed table. This will hit you if you use a global salt and a fast hashing/encryption algorithm.
3: Vulnerability to high throughput custom hardware. This will hit you if you use a fast hashing algorithm like MD5. Modern GPU-based algorithms can churn through hundreds of billions of hashes per second on fairly inexpensive hardware. Which means that attacking, say, 20 million accounts it's possible to run through billions of possible passwords (which means a full dictionary attack, the top million most common passwords, plus common ways of combining words to make passwords, plus every random alphanum string up to 9-10 digits) for each and every account in only a month of work.
4: Vulnerability to very weak passwords. This will hit you if you use a slow hashing algorithm and there's no global vulnerability because you use per-record salts (or bcrypt/scrypt).
4 is where you want to be, always. You can't protect against weak passwords, but you can make it expensive for weak passwords to be revealed, and prohibitively expensive for stronger passwords to be systematically cracked.
The entropy of the hashes isn't really relevant since it's the repeatability of the hashing that's at issue. For example, the hash 7c6a180b36896a0a8c02787eeafb0e4c seems to have plenty of entropy, but since it's the MD5 of the string "password1" and you can just google that hash to find out that information, the theoretical entropy is moot.
Well, if the issue is that your hash is crackable.... ;-)
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.
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.
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)).
They generate one and store it in the database and just do a basic string compare against the one used to auto-login.
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
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.
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.
Store a strongly hashed copy of the password, but use weak hash on password for login token. oops
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).
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).
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.
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.
It's a bad idea to roll your own versions of either the maths part or the applied part, so I don't think the GP was inaccurate in his statement.
Tons of people have created broken versions of popular encryption schemes. They go to Wikipedia, get the AES algorithm, and then implement it. That implementation turns out to be flawed, and by "rolling their own encryption" even if it is based on a very secure one, like AES, they have been incorrectly encrypting content.
But that doesn't apply here. They didn't create their own encryption scheme. Literally, nowhere in the code examples that I have seen did they reproduce either a popular or their own bespoke encryption routine (no maths == no encryption).
Concatenating strings together and then passing it to MD5() is authentication, but the actual hash function implementation is housed entirely within MD5() which presumably is created by someone who didn't screw it up.
People in this thread seem to want to entirely redefine what the term "encrypt" even means to encompass the entire authentication logic but either by the dictionary[0] or Wikipedia definitions[1] that is not correct.
If people want to create a new phase: "Don't roll your own authentication." I am absolutely fine with that. Just don't misappropiate an existing one.
They did it in a trivially stupid way, but it is still a botched attempt at cryptography.
MD5() isn't a primitive, it is an entire implementation.
As I said, if they didn't do maths they didn't do encryption. You're conflating authentication with encryption, which aren't the same thing at all (just like an engine and a car aren't the same thing, or a heart and a human).
Encryption (and or hashing) is an important part of authentication, but the term "rolling your own encryption" clearly relates to the encryption-part of the authentication routine. People regularly roll their own authentication routines (even if that within its own right is a bad plan).
I am in no way defending that code. It is garbage. But people in this thread have clearly misunderstand the warning against "rolling your own encryption." Or don't know what encryption is.
> MD5() isn't a primitive, it is an entire
> implementation.
Commonly used primitives
One-way hash function, sometimes also called
as one-way compression function—compute a reduced
hash value for a message (e.g., SHA-256)
Cryptographic primitives are one of the building
block of every crypto system, e.g., TLS, SSL, SSH,
etc.
...
Combining cryptographic primitives to make a security
protocol is itself an entire specialization. Most
exploitable errors (i.e., insecurities in crypto
systems) are due not to design errors in the
primitives (assuming always that they were chosen
with care), but to the way they are used, i.e. bad
protocol design and buggy or not careful enough
implementation.
That's how I read it — and therefore misquoted it — as well.
In this case hashing functions are being used stand alone (both bcrypt and MD5), and therefore they're not cryptographic primitives. The only time they become cryptographic primitives is when they're used as such, in a cryptographic protocol, which it isn't here. You may have read that Wikipedia entry but I don't think you understood it, it says this quite clearly.
To be honest it is just flabbergasting we're even having this discussion. "Encryption" has a very specific meaning that is hundreds of years old, "crypto" is just a shorthand way of writing encryption or cryptographic, and neither term is a synonym for authentication.
I cannot tell if this confusion originates from people not understanding what the words "encryption" or "cryptographic" mean, or from them not understanding the difference between authentication as a broader topic and encryption/hashing as a singular component within it.
If people want to create the mantra of "don't roll your own authentication," then more power to you. But none of this has anything to do with "don't roll your own crypto." They categorically did not at any point roll any crypto, encryption, cryptographic protocols, or anything else related. Just custom authentication.
As I have said multiple times in this thread: "No maths used == no attempt at rolling their own crypto." It is as simple as that, so unless someone can point me to their bespoke implementation of crypto (i.e. maths) then what you're arguing doesn't make sense.
To use an analogy:
- Famous mantra is: "Never roll your own car engine."
- Article is posted where someone built a custom car using an off-the-shelf engine (even if an old and dangerous one (i.e. MD5)) and it crashes.
- Someone replies: "This is why you NEVER roll your own car engine."
- I reply: "They didn't roll their own car engine, it was a standard off-the-shelf one!"
- Someone replies: "The term 'car engine' (as in "Never roll your own car engine") now refers to the ENTIRE CAR, not just the engine."
- I reply: "No the engine is a specific component in the car." (i.e. MD5 is a specific off-the-shelf component in an authentication scheme).
- Someone replies: "The term 'car engine' now means 'car.'" (i.e. the term "crypto" now refers to the entire authentication process for some reason).
As I said I feel like slamming my head on the table. I don't know another way of explaining this. The fact you think that Wikipedia article has any relation to this topic at all means you're even further from understanding this than I thought. Do you really think an authentication scheme is a cryptographic protocol? Is AES an authentication scheme? Is Kerberos a cryptographic protocol? No, and no. Kerberos USES encryption and AES is used IN authentication schemes, but they're just components in both cases.
They tried to implement a "secure login token" by leaking the user credentials in quasi-plain text (with the advent of rainbow tables then GPUs, MD5 is barely better than Rot13 nowadays).
But still, there's math in that. Strings form a monoid under concatenation and toLowerCase() is a pure function (probably 'map (_ $ 223) source' for a given subset of the domain).
To keep with your (insulting) analogy, they tried to build a car by pouring mayonaise on a crankshaft when they really needed a trumpet.
By doing so, they ruined the protection offered by their otherwise strong password hash.
Don't roll your own crypto. Also, assuming your interlocutor has a modicum of intelligence is basic courtesy.
> It is in the context of building a larger
> cryptographic protocol. But they aren't
> building a cryptographic protocol in this
> case, so none of that applies here at all,
> even a tiny bit.
> "Encryption" has a very specific meaning that is
> hundreds of years old, "crypto" is just a shorthand
> way of writing encryption
> or cryptographic, and neither term is a synonym for
> authentication.
> ...
> I cannot tell if this confusion originates from
> people not understanding what the words "encryption"
> or "cryptographic" mean, or from them not
> understanding the difference between authentication
> as a broader topic and encryption/hashing as a
> singular component within it.
MD5 is a bunch of XORs and MODs. Bcrypt has a bit of that, but mostly it uses Blowfish. Scrypt is used for more or less the same purposes as bcrypt, and is built on top of PBKDF2_HMAC_SHA256. Do you see the difference? Bcrypt and scrypt are built out of things at MD5's level.
Once again, from Wikipedia, https://en.wikipedia.org/wiki/Cryptosystem:
Typically, a cryptosystem consists of three algorithms:
one for key generation, one for encryption, and one for
decryption.
> Do you really think an authentication scheme
> is a cryptographic protocol? Is AES an authentication
> scheme? Is Kerberos a cryptographic protocol? No
People implementing things that use crypto should only be using functions that are "Authenticated Encryption" which specify the full suite like AES-GCM (permutation function: AES, in Galios/Counter Mode), or "Key Derivation Function" (PBKDF2-HMAC-SHA2 or Argon2d-Blake2b). What they've done at AM is implement their own key derivation function using the MD5 primative and concatenation.
But who makes encryption in the first place -- groups?
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.
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.
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
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.
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.
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.
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...
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.
It seems like this has been on the back burner for a while, though ...
Nevermind then, let's go back to berating sysadmins for implementing crypto improperly.
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.
I know, password reset keys are as bad as login keys, but usually they expire after a certain time frame.
F*ck login keys.
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.
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>.
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.
I bet this happens all the time.
I don't think it's fair to say that this was a security oversight, so much as it was a conscience decision to make the system have less friction for users by utilizing these login tokens.
Apart from that, i get about 5 to 10 of real emails like this each month. Looking at the email addresses in Gmail i can see a lot of address that try to use a period in the address.
e: Downvoting questions is mean. FWIW I always use bcrypt.
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.
(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).
Many (most?) users employ the same password on many different sites. So now an attacker has email/password pairs that work not just on the site that was compromised, but also on Gmail, Facebook, Twitter, Amazon, banking sites, and so on.
Not that users don't do it, but that's an invariant he stated.
Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, they won't be able to use any info within it to log in as anyone else unless they use brute force to reverse a hash.
EDIT: It's true that the attacker might have a copy of all the user's data. But unless they know someone's plaintext password, they can't log in as them. The attacker might have a copy of your tweets, but they won't be able to log in as you and send a new one.
There are only a few ways an attacker can snag a database. Most of the attacks let an attacker download it, but not modify it. For example, directory traversal lets you download ../../../../etc/passwd along with ../../path/to/database_backup.
Even if an attacker has shell access, it's unlikely they'd be able to use the service or change a user's password by manipulating the database directly. They might not be able to modify database for a number of reasons: the database might require credentials the attacker didn't get, or the attacker might only have access to a server containing database dumps rather than the database itself, or the attacker might be logging in as a user which has read-only access to the database file.
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own account
Often it's easier to do an injection against a SELECT, just forcing it to read an extra field, particularly now with ORMs that won't pass straight SQL through.
I agree that if the only information you have is a users password hash then your options beyond attempting to brute-force the hash are limited (unless the system was vulnerable to a pass-the-hash attack, of course).
But they wouldn't have the user's credit card, because that's encrypted separately with the key stored somewhere else.
And they wouldn't be able to take action on behalf of the user. That is, they couldn't place new orders as the user, or stuff like that.
Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today.
> If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun
Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.
I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shouldn't be a thing - it certainly should be). I'm saying that it's likely that if they can access the database that contains the user's account details, they're able to access other information that's held in the system anyway (that's what I meant by "game-over").
> Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.
I bet in a lot of cases (not all, would require open-signup etc), you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation.
Password have value beyond one system they can be used to impersonate the user and often they are reused on other sites like email accounts (which can be used with reset password almost everywhere to gain access to those sites).
"you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation."
The hash should also have a salt included (which hopefully is also not stored on the same server as the database) so hashing is salt + password =hashingfunction> hash. The salt can also be a supplemented by a user specific info (unique account id) so that hashes for one user wont' work for another
> and swap out the hash of the privileged user.
True, if the initialization vectors of the hash are the same for admin and regular user accounts (for example, using the same salt for admin and normal users). You would also need write access to the DB via your injection attack.
But it should be clear that a lot of other stuff has to have gone wrong before it comes to that, and - more importantly, why are we all of a sudden so concerned about whether the user's bank account will get hacked? That's the user's problem, not ours, right? If someone's stolen our entire database, things have already got as bad as they can for us - if they're also bad for our users, why do we particularly care?
Fundamentally, if a user has elected to give us their bank password, why is it on us to protect it with military-grade crypto, when clearly the user doesn't think it's sufficiently valuable that they kept it secret? And why should we act as if every password someone chooses to use might be a shared credential?
It seems you're expected to assume that it's your duty to protect customers against any loss they may incur on a third party site because they reused a password, if that password is revealed by someone hacking your database.
But total DB compromise isn't actually the only place in your threat model where you should be worrying about who can figure out a user's password. One very good reason for strongly hashing passwords is to make it very clear that your employees who have legitimate access to the database can not themselves discover users' passwords. This helps maintain the trail of accountability that lets you demonstrate that actions taken by a specific user who logged in with their password were actually taken by that user.
In that sense, the real reason for using strong crypto on user-chosen passwords is because they are secrets which belong to the user and which nobody else should be able to find out about. As such we take extraordinary measures to ensure that that secret is kept. That way it doesn't matter if their secret is that they use a weak, nonunique password. Indeed, how could you even know?
In the Ashley Madison case, of course, it turns out that there are a lot of other secrets that a database can be holding on behalf of a user that should not ever be accessible to anyone else.... but nobody's complaining that the activity history of accounts wasn't encrypted to protect customers against loss after a total data breach.
As an example, if you're a bank, if someone gets your database of data, but the passwords are well protected, they can find out how much money you have in your account. If they get your password, too, then they can login as you and transfer your money to their offshore account.
Consider for example, SQL injection. Alternatively, some kind of DB dump mistakenly exposed in the webroot. Neither should happen but they're real-world examples. Sometimes misconfiguration leaves you in a weird state.
Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the attacker gets the user database and nothing else.
Off the top of my head:
(1) Timing attacks against string comparison (in the hash cases, this usually also implies a guessable salt)
(2) Misconfigured servers showing exceptions/debug info to users, coupled with sensitive information in debug messages, coupled with a remotely triggerable exception
(3) Compromise only of the offsite backup site containing DB dumps but no access to the live DB
(4) Flaky drive is replaced without being physically destroyed. Dumpster diver gets drive working again briefly and gets partial/all DB contents at drive failure time.
(5) Someone else compromises the DB and posts a dump on the web.
Account read-write access opens up a lot more opportunities for fraud and abuse vs. account read-only access.
Typical case, there may be differences depending on what the attacker is after, whether the dump is publicly released, etc.
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.
Edit: moreover, the GP has already mentioned that "[brute force] isn't a zero-cost effort in terms of time," even if you have access to humongous amounts of processing power. The point of encryption isn't to protect data forever; just long enough for them to become uninteresting.
Or, given a strong-enough original password. I postulate that, until the moment I posted it, '3BgZhZcGPcHswmfic79jgjsfqyMKW1Rh1rkFjagJC090V2tljd9Zy2vpYJw944HG' would never have been brute-forced, even with an extremely low work factor (in fact, it wouldn't have been brute-forced even without bcrypt, scrypt or PBKDF2: even were it just stored as a simple SHA2-512(pw) (i.e., baafbe64d25f27d4b7b2965f9abf43cf25acd8fc6021798a90253f33b3071e9 fd145eaccd555290913c8679fd4acf949f05243ac1089548abbab0e0ed77e63 31), no computer on earth, nor all the computers which ever have been or ever will be, would have brute-forced it (unless there's something we don't know about SHA2, or about computing).
Lesson? Always use high-quality random passwords. For a 128-bit security level, with upper- and lower-case letters & digits (62 characters, which means each character yields (log 62 2) = 5.9542 bits of entropy), you want a 22-character truly random password. 'xNl5gkbgXntyxi3oNO1dML' is a perfectly fine password (save for the fact that it's now public).
According to the NSA [1], 256-bit keys should be used to protect data up to TOP SECRET; that works out to 43 characters. Hence, 'TIdmzj1COc9ECwcilyQYVfLl5Dt8ti3UUlDVULrUrfx' is as secure an example password as could be.
(Yes, I'm assuming here that your password-generation algorithm is truly random. If not, do not pass Go; do not collect $200…)
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
(Though I've heard noises recently about KeePass's .kdbx file format having some known vulnerabilities. Anyone else heard this, or have more details?)
This doesn't seem like a particularly scary vulnerability, but one scenario that was brought up (though I'm not 100% convinced), is that a malicious actor can corrupt the password for one website, leading you to change the password.
I dunno, don't see it as a huge vulnerability, but I do agree there is little reason for such a database not to be authenticated.
Glad this happened to them. 'bout time Karma came a'knocking.
Oh, p.s. can confirm all women (at least 90%) are bots.
He ran a website for men wishing to cheat on their wives. The one follows the other as night follows the day.
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 ?
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.
Edit: clarified. BTW hash_hmac is built-in with PHP >= 5.1.2.
That's why bcrypt and the like are popular, because you can adjust how long it will take to calculate.
Myopic Ensurer