Fdtxjr

When you hear that passwords got stolen, sometimes companies will report it even if it's just hashed passwords that were stolen. This is so you can take action in the case that they are broken. Unfortunately, there are still companies that store their passwords incorrectly; for example, if you search for the rockyou password breach, you'll find that they were storing their passwords in clear text, which means that they were compromised as soon as they were stolen. In other cases, such as the Adobe password breach, there was mishandling of storing the encrypted passwords in their database. Other times, companies use hashing on their passwords but use insecure hashing algorithms or they don't salt their passwords properly. In short, if a company follows recommended password storage methods, the passwords in theory should be safe in their hashed form, but a good company will still inform their customers of the breach. However, there are plenty of examples where companies do not store passwords correctly leading them to be cracked quite quickly.

You hash a large number of potential passwords^*, then check whether each output matches any hashes from the stolen password database. Brute force cracking is feasible because people do not usually choose highly unpredictable passwords.

When a password database is stolen, the stolen material includes all the information necessary to do offline cracking. (It's simply a guess and check process. Other methods may be available with less secure hashing or password storage methods.)

^{_{* If salts are used, then the cracker must consider those too. If each account uses a unique salt then crackers can't simply target everyone by hashing every candidate password once. If multiple accounts are being targeted then the password you want to try has to be hashed one time for each salt. If password hashes are unsalted or all use the same salt it's a lot easier to do untargeted attacks; you would only need to hash a candidate password once to figure out the full list of users that had that password. Salts also render useless attempts to use precomputing of hashes to save cracking effort. Salts DO NOT reduce the number of hashes that need to be evaluated if only one account is being targeted. Those nuances aside, the basis of password cracking remains a guess and check process.}}

Hashing passwords with a preimage resistant functions with a sufficiently unpredictable input is enough to make it impossible recover a password. (An inhumanly strong password.)

However, most people don't do this in the real world, a stolen database of hashes is potentially as worrying as a list of unhashed passwords for a large subset of users on a typical website.

If the password cracker finds candidate password whose hash matches the one stored in the database, then he will have recovered the original (weak) password.

Alternatively, if a hash function is not preimage resistant (including when the output of the hash is too short) a guess-and-check procedure may produce false positives. (Alternative passwords not identical to the original.)

The accounts of users from the company with the data breach are still vulnerable because these passwords will unlock a user's account, even if they aren't identical to the original password. (The server has no way to tell if it's the original password. The hash still matches the one in the stolen database in this case.)

Don't intentionally use an insecure hash function, of course... It's still possible to infer the original password or narrow down the number of possibilities. Which would still make users that reuse passwords on other websites extra vulnerable.

There are other ways passwords can get stolen which don't stem from a copy of a database of password hashes getting leaked. Plaintext login information could be logged. (By observing unencrypted/decrypted network traffic, by hacking and rewriting server code, or utilizing client side bugs, for example.) Then that log can be exfiltrated.

And of course some companies might not have been using secure password verification schemes in the first place or may leak the plaintext through a bug^1,2.

Despite the alternative explanations for some instances of mass password breaches, plaintext passwords recovery from password hashes is common and effective. It is not so effective, however, that 100% of the hashes in every large database leak will be recovered.

If passwords are processed with a cryptographic hash function, then users with extremely strong passwords do not need to be as worried as typical users. (But most people over estimate password strength and their own cleverness.) After spending significant resources to crack 99% of the hashes it probably isn't worth it or practical to crack the last 1%. But strong passwords are no good if passwords aren't hashed.

Developers should use a password stretching algorithm. These algorithms just try to make password hashing more expensive. (For both legitimate users and password crackers.) Argon2 is currently the best password stretching algorithm, especially on Intel/ARM CPUs. Argon2 specifically can go a very long way to reduce the fraction of hashes which will get cracked. (Weak passwords will still be crackable.)

Many possibilities:

1. Even though passwords should be hashed before storage, it's not always the case. Sadly, even today, there are still plenty of passwords stored as cleartext. Steal database, get all passwords.




2. Passwords could be stored somewhere else. Passwords could be included in logs, for instance. Steal logs, get all passwords that were used in those logs.




3. Passwords could be hashed but not salted. So you build a list of password -> hash combinations based on all sorts of passwords. You reverse this table so it becomes hash -> password (lookup table). Get database, convert hashes to passwords, get lots of passwords.




4. Passwords are hashed and salted. But lots of users use very weak passwords (123456, password, letmein, qwerty...). Try lists of passwords against those hashes. Get database, make a dictionary attack on hashes, get lots of passwords.




5. Variation on the previous one, instead of a pre-determined list of passwords, try passwords based on other information you have about the user (username, first name, last name, date of birth, e-mail...).




6. Yet another variation, as many users re-use the same password: try passwords for the same e-mail/username recovered from other breaches.




7. Yet another variation, when there is a strong password policy in place which requires changing passwords on a regular basis: if you have a previous password for the user, just try changing the final numbers: if user had password "joe12" at one point, try joe13, joe14, joe15... If you have the date the initial password was valid and know the password change interval, it can be quite quick.




8. Passwords are hashed and salted, but use weak (fast) hashes. Same as #4-7, but you can do a lot more attempts a lot more quickly, so you can try a larger dictionary, or even try quite systematically all combinations (brute force attack).




9. Communication between clients and servers are susceptible to man-in-the-middle (MITM) attacks. Passwords are captured on the way.




10. You perform social engineering. "Hello, this is the IT department, there's an issue with your account, we need to reset something, can you give me your password"? You'd be amazed how often that works if properly framed.




11. Mass social engineering, aka phishing: send a mass e-mail campaign asking to log into a site which will capture all those passwords.




12. Hack into the site, and modify it so it sends all passwords received to a remote server (or logs them to a file you'll retrieve later).




13. Ditto, but modify client-side code to do it. Could be as easy as a stored XSS hack.




14. A variation on the above: keyloggers.

There's probably quite a few more methods, but that gives you an idea of how easy it can be to recover tons of passwords.

As we are not discussing how the passwords have been stolen, and more so the aftermath, I'll avoid the many number of factors said companies should implement to help prevent these data breaches.

If you make a website and manage the database, it's down to us to store that information efficiently. If we don't, when there is a data breach attackers can view passwords in what may as well be plain text, as often is the case (depending on the way in which these are stored).

In short, you'd never want this to happen! -- Password cracking is a very common and real thing, just because passwords are hashed does not make them in any way secure.

Let's say a company has 1000 customer passwords, all of which are hashed.

Let's say 600 of those customers had a password, 8 characters long, the likelihood of those passwords being cracked within the first 5 minutes (being generous) is very high.

"5 minutes?! But they were hashed!"....

Yeah, but the passwords of those 600 customers were still poor, along with an equally poor hashing algorithm.

Without going into too much detail in the interest of simplifying the explanation; password cracking works by simply matching the hash to a dictionary file of words, running through each word to see if their hash matches the ones that have been obtained from those 600 customers, for example, your password might be:

Password: Security

MD5 Hashed: 2FAE32629D4EF4FC6341F1751B405E45

I then just run some favorable hacking tools against those hashes to "crack" them.

Should you ever want to store passwords yourself, MD5 should be avoided, above was purely for example purposes. Instead, research the stronger types of hashing algorithms, it makes it much harder for attackers to successfully make use of the passwords they have stolen.

The short answer; hashing, or whatever format you store your passwords has no effect on the ability for hackers to steal these. They are stolen because of a variety of different vulnerabilities. There are a multitude of attacks in which help obtain passwords (hashed or not).

One particularly important point is that when the password database is secure and only accessible to the legitimate service, someone trying to access an account can only try them out individually via the legitimate service. Repeated failed attempts can be noticed, an automated alert provided, and appropriate action taken to limit further login attempts from the same source.

Once the password database is stolen, and details of the hashing algorithm are known, the person(s) in possession of the stolen password database can try millions or billions of passwords against their copy of the database without causing any further alert to anyone, and when they've found one that works on their offline copy, only then do they attempt to access the legitimate service impersonating one of the users of that service (maybe you!).

A significant proportion of users have passwords that are likely to be in the first billion that an attacker would try, so it's only a matter of a relatively short amount of time before the attacker can access a significant proportion of accounts.

Those users who really do have strong passwords, should be able to safely ignore a compromise where only hashed passwords were leaked, but many users do not in fact have sufficiently strong passwords to resist this kind of offline attack, merely ones that seem strong enough to the sites automated password strength checker, which is normally more concerned about ensuring accounts are sufficiently strong to resist online attacks against the legitimate service.

Also take the following attack vector into consideration for web applications:

If the attacker can modify the frontend code, then with a small script the plaintext passwords could be "sniffed" for a while.

If the script can be injected from the backend, then it could be set to only show for visitors from certain countries to better protect against malicious frontend code change detection automations in place running in the same country where the application is being run from.

While storing passwords in hashed form is desirable, it can also pose some difficulties. If it is necessary for one entity to issue a request to another entity on behalf of a user, and the second entity requires submission of plaintext passwords for validation, the first entity will need to hold the user's password in a form that would be convertible to plaintext.

To allow for this, companies may store passwords in various kinds of hardware security modules which audit all attempts to retrieve passwords from them. This approach mitigates many of the dangers involved with plaintext password storage. It can't mitigate all of the dangers, but if an entity is supposed to have authority to access an outside entity on behalf of a user, and the outside entity won't accept anything other than the user's password as evidence of that authority, some of the dangers associated with plain-text passwords will be inescapable no matter what the first entity tries to do.