Everywhere I look it says servers store passwords in hashed form, but then you have those breaking news about hackers stealing passwords from large companies. What am I missing?

  • 7
    Passwords could be stolen also by eavesdropping them on the points they pass unencrypted. And at least on a point they are unencrypted, namely on the keyboard of the user.
    – peterh
    Mar 16, 2019 at 21:04
  • 136
    "Everywhere I look it says servers store passwords in hashed form" No, it says servers should store passwords in hashed form!! Mar 17, 2019 at 1:18
  • 14
    If you password is "123abc", no amount of hashing, salting or peppering will keep your account secure once the database is stolen. Mar 18, 2019 at 9:02
  • 1
    You also need to educate people about security. If your password has enough entropy, you use hashes and salt but your employees write down passwords on post-it and leave them around, or just give them to that colleague who "really needs that file on the server" you will have problems. Look up "Social Engineering"
    – Axel2D
    Mar 18, 2019 at 15:55
  • 6
    I worked a food counter for long enough that for a half-dozen combos, if you told me a customer's total, I could tell you what they ordered, without a receipt or knowledge of their particular order.
    – dandavis
    Mar 18, 2019 at 19:02

8 Answers 8


There are two common failings, over and above letting the databases or files get stolen in the first place.

Unfortunately, and against all security recommendations, many systems still store plain text passwords.

Hashed passwords are technically not reversible, but as has been pointed out by others, it's possible to hash millions of password guesses then simply look for matches. In fact, what usually happens is that tables of pre-computed passwords and hashes (Rainbow Tables) are available and used to look for matches. A good rainbow table can support a high percentage match in fractions of a second per password hash.

Using a salt (an extra non-secret extension of the password) in the hash prevents the use of pre-computed rainbow tables.

Most compromisers depend upon rainbow tables. Computing their own hash set is certainly possible, but it's extremely time consuming (as in months or longer), so it's generally the vanilla hash that's vulnerable.

Using a salt stops rainbow tables, and a high round count of hashed hashes of hashes can make brute force transition from months to years or longer. Most institutions simply don't implement this level of security.

  • 35
    I disagree with your statement "most compromisers depend upon rainbow tables". While they are useful in some situations, evidence suggests password cracking is still more popular since it is remains useful regardless of salting, different hash types, and iterative hashing.
    – PwdRsch
    Mar 17, 2019 at 19:54
  • 5
    Salts don't prevent the use of precomputed rainbow tables or stop rainbow tables. They merely make it orders of magnitude harder. Remember, it's possible (but so unlikely we can safely pretend it will never happen) that a random number generator could guess your password on the first try.
    – CJ Dennis
    Mar 17, 2019 at 23:16
  • 2
    "Hashed passwords are technically not reversible"... true but misleading, since you don't need to reverse it, you just need a preimage that hashes to the same thing.
    – user541686
    Mar 18, 2019 at 1:02
  • 9
    "...many systems still store plain text passwords." Yup. About 2 years ago, we received a copy of a database that we were building a replacement for. (We were going to migrate data over.) Whoever dumped it and sent it to us didn't bother to scrub all the plain text passwords from it, meaning I could have gone in an impersonated anyone I wanted on a live government system.
    – jpmc26
    Mar 18, 2019 at 18:17
  • 5
    The website plaintextoffenders.com maintains a list of companies found to be storing your passwords in plaintext or some other recoverable format. The list currently has over 5,000 entries. Mar 19, 2019 at 9:31

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.

  • 2
    And even if you do everything right, stealing all the hashed passwords (along with usernames or e-mails, presumably) makes it much easier to do other attacks on the passwords - especially with old mechanisms like MD5, salting or not. And given that most people use the same password on multiple sites, and the passwords are still quite weak often enough... Granted, if you use a good slow hash with proper salting, the impact is very low.
    – Luaan
    Mar 18, 2019 at 8:16

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 bug1,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.)

  • 1
    "You hash a large number of passwords, then check if the output matches any of the stored hashes." Salting defeates this.
    – Taemyr
    Mar 19, 2019 at 6:51
  • @Taemyr It's not clear to me this means pre-computed hashes, though it could be a little clearer. Salting only makes dictionary attacks more computationally difficult, and pre-computation impossible. Mar 19, 2019 at 17:16
  • @Taemyr Except if they have managed to compromise your systems enough to steal your database, they may also have managed to steal your salt.
    – Dijkgraaf
    Mar 19, 2019 at 18:03
  • I did not want to complicate things further by going into salting but at this point I may as well since the question got more traffic. Ideally I would state the same information in a simpler more organized format... The web tends to oversimplify the reason for using salts to "it's more secure" or "it's totally secure". They make the herd safer, but not the individual. Salts can be completely effective against "reversing" hashes using lookup tables. They don't do much at all to slow down targeted attacks. But anyone not using long random unique salts has made a massive mistake. Also, use Argon2 Mar 20, 2019 at 5:21

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.

  • Number 7 for me is just genious
    – gota
    Mar 19, 2019 at 17:15
  • This is by far the most complete and accurate answer. Mar 19, 2019 at 17:18

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

  • 12
    Just to note that with a weak password like 'Security', you don't even need a cracking tool, you can just Google 2FAE32629D4EF4FC6341F1751B405E45
    – richardb
    Mar 17, 2019 at 15:15
  • 3
    And even more so, now that this article is indexed! Mar 18, 2019 at 17:47
  • Just as a note: While MD5 should not be used at all in preference to newer algorithms like SHA2 or SHA3, for password hashing those are almost equally bad, just because they are too fast. Use an iterated hash like PBKDF2, bcrypt or scrypt with suitable security parameters instead. Mar 23, 2019 at 17:39

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.

  • I'm unclear under what circumstances such a second entity one allow a first entity to impersonate a significant group of users, and fail to provide that first entity with an appropriate authentication mechanism. In many cases, a user providing to such a first entity their password to access the second entity would be in violation of the second entity's terms of service. Is there a concrete example of such a first entity/second entity?
    – Steve
    Jul 20, 2020 at 9:00
  • @Steve: I was thinking about things like automated tools to do things like post messages at certain times, check for messages on one service and forward notifications (and/or the message contents) to another, etc. Having a service support some form of proxy credentials that could be shared with the automated service without having to share the primary credentials would be better, but that would require cooperation by the provider of the primary service. Another related situation would be with facilities that need to synchronize passwords among services that store them differently.
    – supercat
    Jul 20, 2020 at 15:33
  • If company X inherits/acquires a system Y to which all X's users are supposed to automatically receive using their current credentials, but Y's authentication mechanism hashes passwords differently and X can't change it, how should X create accounts on Y without having Y's passwords stored somewhere? If X uses secure hardware storage modules which would be unable to decrypt user passwords without having at least five out of eight private keys, each of which only exists in one place in the universe, and the holders of those keys all supervise all actions that are done using them, ...
    – supercat
    Jul 20, 2020 at 15:40
  • ...then it may be possible to maintain security over passwords despite the fact that the database could be decrypted under the right circumstances. Note that I've seen some situations where companies require inappropriate credential exposure, such as a satellite network which requires users to provide satellite-provider credentials in order to access streaming content (presumably so the network can use the customer's account tools to confirm that the customer is actually subscribed, but there's no reason the satellite provider should make that necessary!).
    – supercat
    Jul 20, 2020 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .