Note: This is not an actual situation I'm currently in.

Assume your boss is one of those old-fashioned computer-illiterate managers and wants to store the passwords in plaintext to simplify development. You get 5 minutes to explain the point of hashing passwords. You also know from experience that your boss can be swayed by a good analogy. What analogy would you use to explain your boss that passwords should be hashed?

  • 80
    When technical talks fall on def ears, it may be time to start talking liability. Commented Jul 18, 2014 at 11:35
  • 36
    @Nate: To those bosses, you explain that they may feel fine about accepting the liability, but that you don't, so if they could please sign a waiver accepting on behalf of the company all liability for the technical decision (i.e. not hashing) that they made and you executed. That pulls the moment forward when they have to think.
    – MSalters
    Commented Jul 18, 2014 at 14:30
  • 26
    Here's an analogy: once there was a King who didn't want to hear about what was going on in his kingdom. He was a very important person who didn't have time to think things through. But because he was in charge, he had to make lots of decisions. He wouldn't be much of a King if he let his advisors do what they thought best! So he ordered his advisors to tell him invented stories and then ask him what he would do in the story. Naturally his kingdom was invaded, he was killed, and his castle razed to the ground. But at least he didn't have to think about it, and he enjoyed the stories. Commented Jul 18, 2014 at 17:37
  • 3
    "Because if you don't, the first time you make me angry, I'm going to use your password to sign on as you and transfer some of the company's assets to your name." Commented Jul 19, 2014 at 22:49
  • 4
    Because you are the developer, and it's your job to make secure software -- your boss hired you because you know computers and he doesn't -- and you have an ethical and professional obligation to do so.
    – Max
    Commented Jul 20, 2014 at 8:20

18 Answers 18


The Short Answer

The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper.

But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more.

Why you need to do more takes a bit longer to explain. So let's take the long route for a moment so that you understand what you're explaining, and then we'll circle around for your 5-minute synopsis.

Hashing is just the beginning

But let's start with that. Say you store your users' passwords like this:

# id:user:password

Now, let's say an attacker manages to get more access to your system than you'd like. He's only there for 35 seconds before you detect the issue and close the hole. But in those 35 seconds he managed to snag your password database. Yes, you made a security mistake, but you've fixed it now. You patched the hole, fixed the code, updated your firewall, whatever it may be. So everything is good, now, right?

Well, no, he has your password database.

That means that he can now impersonate every user on your system. Your system's security is destroyed. The only way to recover is to start over with NEW password database, forcing everyone to change their password without using their existing password as a valid form of identification. You have to contact them out-of-band through some other method (phone, email, or something) to verify their identity to re-create their passwords, and in the mean time, your whole operation is dead in the water.

And what if you didn't see him steal the password database? In retrospect, it's quite unlikely that you would actually see it happen. The way you probably find out is by noticing unusual activity on multiple users' accounts. Perhaps for months it's as if your system has no security at all and you can't figure out why. This could ruin your business.

So we hash

Instead of storing the password, we store a hash of the password. Your database now looks like this:

# id:user:sha1

Now the only thing you store is an opaque token that can be used to verify whether a password is correct, but can't be used to retrieve the correct password.

Well, almost. Google those hashes, I dare you.

So now we've progressed to 1970's technology. Congratulations. We can do better.

So we salt

I spent a long time answering the question as to why to salt hashes, including examples and demonstrations of how this works in the real world. I won't re-hash the hashing discussion here, so go ahead and read the original:

Why are salted hashes more secure?

Pretty fun, eh? OK, so now we know that we have to salt our hashes or we might as well have never hashed the passwords to begin with. Now we're up to 1990's technology. We can still do better.

So we iterate

You noticed that bit at the bottom of the answer I linked above, right? The bit about bcrypt and PBKDF2? Yeah, it turns out that's really important. With the speed at which hardware can do hashing calculations today (thank you, bitcoin!), an attacker with off-the-shelf hardware can blow through your whole salted, hashed password file in a matter of hours, calculating billions or even trillions of hashes per second. You've got to slow them down.

The easiest way to slow them down is to just make them do more work. Instead of calculating one hash to check a password, you have to calculate 1000. Or 100,000. Or whatever number suits your fancy. You can also use scrypt ("ess-crypt"), which not only requires a lot of CPU power, but also a lot of RAM to do the calculation, making the dedicated hardware I linked above largely useless.

This is the current state-of-the-art. Congratulations and welcome to today's technology.

Are we done?

So now what happens when the attacker grabs your password file. Well, now he can pound away at it offline instead of making online guess attempts against your service. Sadly, a fair chunk of your users (4% to 12%) will have used the password "123456" or "password" unless you actively prevent them from doing so, and the attacker will try guessing these first.

If you want to keep users safe, don't let them use "password" as their password. Or any of the other top 500, for that matter. There's software out there to make accurate password strength calculation easy (and free).

But also, multi-factor authentication is never a bad call. It's easy for you to add to any project. So you might as well.

Now, Your 5 Minutes of Glory

You're in front of your boss, he asks you why you need to use PBKDF2 or similar to hash your passwords. You mention the LinkedIn class-action suit and say, "This is the minimum level of security legally expected in the industry. Anything less is literally negligence." This should take much less than 5 minutes, and if your boss isn't convinced, then he wasn't listening.

But you could go on: "The cost of implementing hashing technology is negligible, while the cost of not implementing it could be in the millions or higher." and "In the event of a breach, a properly-hashed database allows you to position yourself as a well-run security-aware organization, while a database improperly hashed is a very public embarrassment that, as history has shown many times over, will not be ignored or overlooked in the slightest by the media."

If you want to get technical, you can re-hash the above. But if you're talking to your boss, then you should know better than that. And analogies are much less effective than just showing the real-life effects that are perfectly visible with no sugar-coating necessary.

You don't get people to wear safety gloves by recounting a good analogy. Instead you put some lunch meat in the beaker and when it explodes in green and blue flames you say, "that's what will happen to your finger."

Use the same principle here.

  • 4
    One comment: I looked up that Linkedin lawsuit, and it was dismissed (although the reason for dismissal was not because the passwords poorly hashed). I will show it to my coworkers though, because it shows potential consequences for using SHA-1. I also found a website with 15 billion SHA-1 hashes that I will use as further evidence.
    – Nzall
    Commented Jul 19, 2014 at 15:59
  • 58
    'You don't get people to wear safety gloves by recounting a good analogy. Instead you put some lunch meat in the beaker and when it explodes in green and blue flames you say, "that's what will happen to your finger." ' Using something vaguely finger-like to demonstrate what will happen to somebody's actual finger is literally an analogy. Commented Jul 20, 2014 at 9:07
  • 4
    2FA/MFA can sometimes be "a bad call". If you force every user to use it all the time in low-security circumstances, you can very quickly create security fatigue. I don't want to have to submit an iris scan and stool sample every time I log into Facebook. If your data isn't that risky, make 2FA/MFA optional. You'll make security-paranoid users happy without exhausting the lazies, plus you get to shift some liability onto the people who opt out.
    – Oli
    Commented Jul 21, 2014 at 10:28
  • 20
    I googled the first hash. The first result was "How do you say 1f6ccd2be75f1cc94a22a773eea8f8aeb5c68217 in German?"
    – Dracs
    Commented Jul 22, 2014 at 2:13
  • 4
    @woliveirajr crackstation.net has a 190 GB database with 15 billion passwords and hashes for MD5 and SHA-1. They also have a 19 GB database with 1.5 billion hashes for a number of other hashing algorithms.. I've tested it for the example hashes and it works.
    – Nzall
    Commented Jul 22, 2014 at 7:09

This thread is a bit short on analogies, so here goes:

An unhashed password is like a transparent lock, anyone who gets a proper look at it can design the matching key.

  • 1
    I'd go with unhashed = comparing keys, and unsalted = transparent lock
    – Bergi
    Commented Jul 27, 2014 at 11:00
  • @Bergi I can't make a snappy sentence from that, and given the way you are delivering the suggestion I guess you couldn't either. Commented Jul 27, 2014 at 14:34
  • 3
    Not as snappy as yours maybe, but I'll try: An unhashed password is like a spare key, which is compared to match the user's one. Everyone who gains access to the key room could make copies of them however. So we don't store keys, but we store locks which need to be opened by the user's respective key. Still, with access to the lock room one could pick the locks, and since they're all transparent and of the same manufacturer it's quite easy to find a pick that will open some. So, we salt our hashes, which is like using many different lock models so they need to be picked individually.
    – Bergi
    Commented Jul 27, 2014 at 14:56
  • Unfortunately I can't post it as an answer, even if it nearly exceeded the comment length limit :-)
    – Bergi
    Commented Jul 27, 2014 at 15:03
  • @Bergi Points for trying, but that explanation ends up being almost as complicated as the plain explanation of password hashes. The point of the analogy isn't to replace the actual explanation, it is more like a decision making lifeboat for those who fail to grasp the real explanation. For that purpose being simple and memorable is extremely important features. Commented Jul 27, 2014 at 16:59

To start off, I'll provide one to start with:

Imagine you manage a bank. You don't want to allow your customers direct access to the money. So you have a teller who has just a computer and a small amount of money to deal with everyday withdrawals and deposits. He cannot access everything, nor can he pass secrets to the customer, because he doesn't have access to these secrets.

A teller is all fine and dandy, but sometimes, you have a person who wants to rob the bank and he's not really going to get stopped by the teller. To counteract this, you have a really big safe in your basement that contains all the real money of your clients. this safe has a bunch of security, like a fingerprint scanner, voice recognition, pressure switches, triple-keyed locks and a timed lock. it's designed to keep out everyone who shouldn't be there and who doesn't know how to get past the security.

This safe will stop 99% of the robbers, but there is always that 1% that manages to get past all that security, either by bypassing it or by brutalizing it. In case that happens, a bank stores their money in boobytrapped containers, that turn the money unusable, through means like blowing it up or spraying paint all over it. That way, the robber either cannot use the money or needs to spend a long time to make the money somewhat usable again.

A software application has these systems as well: the program that the user uses is the teller: he cannot make it do whatever he wants it unless he finds a way to sweet talk it into cooperation. the hardware and software configuration that protects the program and the database is the bank vault: it keeps the people out who don't know what the weaknesses are of the used security configuration. Storing the password in cleartext means that if someone gets past the program and the security configuration, he has free access to the passwords. Just like a bank stores the money in a container that makes accessing the money far harder, hashing the password gives the person who compromises your passwords a giant hurdle he needs to climb. It also means that the employees (both the bank, the software and those of our own company) cannot be pressured, coerced or sweet talked into bypassing the security for a con man, because not even they can access the money/passwords directly. They can only access the containers/the hash.

  • 1
    you lost me at hashing the password (is) a giant hurdle (which is typically why I don't like analogies)
    – njzk2
    Commented Jul 18, 2014 at 21:15
  • 5
    @njzk2 "X is a hurdle" is such a common phrase that it's barely even an analogy. It's just an idiomatic way of saying "X makes the task difficult." Commented Jul 20, 2014 at 9:12

I like analogy as a way to explain technology, however in this case it's probably not workable as the analogy would be too complex.

Most managers are more motivated to avoid personal risk to their position than doing the right thing, so rather than an analogy I'd use examples where storing passwords in plain text has reflected badly on a company. I'd just say something like

"Storing passwords in plain text would make us look very bad, risking our reputation and possibly opening ourselves up to litigation. It is considered very bad practice in any industry, and there are websites devoted to naming and shaming companies that store passwords in the clear. Personally, I wouldn't like to be the one standing in front of the board/boss/CTO explaining why we didn't put a basic security control in place. If we hash our customer's passwords a data breach wouldn't cause an immediate leak of passwords hackers could use, and we would be seen to be protecting our customers' information. Hashing passwords mitigates a big risk for little effort. "

Include with it links to Plain Text Offenders, and then send likes to some news stories like Cupid Media, Microsoft India Store, etc.

  • 1
    +1 for Plain Text Offenders - showing your boss that the company would get ridiculed in public, by a site which does a great job of explaining and defending why they do that, seems pretty easy. Especially since it is so easy to implement good practices
    – nealmcb
    Commented Jul 19, 2014 at 2:35

Using analogies can be powerful, but in this case, I think it would be much easier to just explain in simple language what is going on. Something like this should be effective, but probably should include powerpoint slides with illustrations and large corporate fonts.

As you know, we require people to use passwords so that we know who they are when they are using our product. We have to keep track of these passwords in order to let people log in. The problem is, we can't store the passwords exactly as they are entered, because attackers have found ways to be able to see them and steal them.

We also can't just rewrite the passwords in a clever code and believe that we will be the only ones who know how to translate the code, because that still doesn't guarantee that determined attackers can't figure out the code, and it also doesn't protect against attacks from inside our organization, such as rogue ex-employees.

To solve this, we must use a one-way password hash. A password hash is like using a code, except that it is impossible to decode.* This way, only the user knows his or her password. We only store the hash of the password and check it when the user logs in. This keeps our users safe and reduces our liability in the case of a data breach, which can have severe repercussions. [Include examples of companies that have been sued for insecure password storage]

* [I know it's not impossible, but probably the layman doesn't need that much detail.]

  • Why doesn't this have more votes? Also, you should probably add that, if the passwords are stored in plaintext, a malicious internal user (say that shifty-looking guy down the hall) could access them and then use -- or worse, sell -- them.
    – Doktor J
    Commented Jul 18, 2014 at 20:12
  • 1
    I tried to use this simple language to explain password hashing to my wife. She got stuck on the concept of a one-way function. Any ideas on simple language to explain that?
    – Nomic
    Commented Jul 24, 2014 at 11:29
  • 6
    @Nomic A one way function can be explained as the function that generates a persons shadow from 1000 angles, by using that persons entire appearance as input. You can completely determine what a persons shadow will look like based on the persons appearance, but the reverse is harder. Generating a 3d shape that creates the same exact shaows from multiple directions would surely take tons of scultping and revising (though a 2d cutout would work for a single angle.) To gain access, we must compute the 3d shape, since only a 3d shape is accepted as input. Knowing all the shadows is not enough.
    – Allen
    Commented Jul 24, 2014 at 16:24
  • @Nomic Trying it out is an excellent idea! Allen's analogy is really good; I would recommend that over simple language to elaborate on the one-way hash, but for the fun of it, here's my attempt at simple language: A one-way password hash takes some text and does clever math on it so that it turns into a very long and incomprehensible jumble of letters and numbers. It's different from using a code because it cannot be turned back into the original input. Commented Jul 24, 2014 at 16:26
  • @Allen I liked the simplicity of your first comment, but either way, the shadow is a great analogy Commented Jul 24, 2014 at 16:27

All explanations so far are a bit long, here is a short one:

Some people who can't remember their bank pin, keep a note in their wallet.

If a thief or aquaintence would get to look inside the wallet they'd have a problem, UNLESS the pin is written in a way that they can't read it.

Hashing is basically writing text in a way that nobody else can read it.

  • Could be expanded to make it more tangible how you would write a pin in a way that nobody else would understand. Commented Jul 18, 2014 at 14:30
  • 1
    Upvote because it's a nice quick analogy which gets across the importance, but the implication is that you can recover the PIN from the note if you know the "way the owner can read it" which implies encryption rather than hashing.
    – moopet
    Commented Jul 18, 2014 at 15:54
  • 8
    As much as I like the simplicity, this analogy fails to capture the idea that hashing is a one-way process, so it depends on how much you think the layman needs to understand that. Commented Jul 18, 2014 at 16:29
  • 1
    You're confusing hashing with encryption. If you can read the password, you've failed in protecting your user's private information, and put yourself at great legal risk.
    – nealmcb
    Commented Jul 19, 2014 at 2:36
  • 2
    @nealmcb I realize that this does not actually explain hashing, but it does explain the point of hashing. As such I believe it answers the question. Commented Jul 28, 2014 at 10:03

Imagine you're the bouncer at a club. To know whether to let people in, you have a codebook of people's names/aliases (some people prefer to be discreet, and are only known by an alias) and their own private passwords; you can't recognize that people are or aren't who they say they are by their voice or appearance (there are too many people, and due to the aliases, ID checks are a no-go), so you just have to go off of the book (the web server can't tell by looking at you that you're the wrong person). People have to tell you both their name and password to get in, and if it doesn't match your book, they're turned away.

If somebody gets a picture of your codebook (your DB is leaked), they can impersonate anyone they want to, without you being able to tell they're lying. Some of your customers also use the same name and password at their bank (who have tellers who work off of codebooks just like you), and so they'd have money stolen that way. You'd then be fired for allowing such a major breach, making the club look very bad, and costing them money.

Fortunately, you can buy a black box (hash function) that takes their name (salt) and password and gives you a long random-looking number (hash) that will always be the same for a given name and password, and different for any other combination of name and password. So now instead of your codebook containing [name and password], you can have it just contain [name and number]! When a person wants to get in, they tell you their name and password, you feed that into your black box, and you lookup their name in your codebook to check that the number your black box gave you matches the recorded one.

Now if someone gets a picture of your codebook, they still won't be able to get in! They won't even be able to tell if half of your people use the same password, because each [name and password] combination fed into the black box was unique. They have a black box just like yours, and can feed in a certain name and random passwords until they find the right number, but they have to do that for each person individually.

If you discover that it was leaked, you should still have your customers change their passwords for maximum security, but the attackers won't have an easy time of getting in.

  • This codebook is written in Braille? Commented Jul 22, 2014 at 20:18
  • Yes. ;) I actually thought of putting that in, but it hurts the "someone gets a peek at/picture of your codebook" snooping analogy. If it helps, the book is written in braille, but with clearly-visible dots, and is all on one sheet of paper. (QR code braille?)
    – Tim S.
    Commented Jul 22, 2014 at 20:20
  • Or, if you like, you can see, but the club is a masquerade club, where everyone wears masks when they enter. And..masquerade..banks exist in this universe. Stop asking questions! ;)
    – Tim S.
    Commented Jul 22, 2014 at 20:23
  • @PaŭloEbermann I've removed the blind part. In the end, I decided it didn't add much to the analogy, and weakens it.
    – Tim S.
    Commented Jul 23, 2014 at 16:41

Explain it in terms of lines of defense.

Obviously, you're going to be doing everything you can to make sure that your code is secure. But the fact is, your server will not only run code that you wrote, and you have no control over the code written by other people. Even if all of the other code on the machine is open-source, you would need to hire another 2-3 full-time developers to take responsibility for your own branches of everything. Since -let's not kid ourselves- this whole thing is supposed to be a cost-cutting measure, that is not feasible way to go.

Thus, even if you had absolute confidence in your own code, there would still be plenty of room for things to go wrong. You therefore need a way to ensure that even if an attacker gets into the machine, your passwords are still safe. This is where "hashing" (in quotes because the proper algorithms to use in this day and age aren't really hashing algorithms, per se, but it's still a useful catch-all term) comes into play.

In military terms, this is essentially how (and why) you set up multiple lines of defense. No general puts the entire military in the same spot, because you need to account for the possibility that something you didn't foresee allows your front lines to be defeated or bypassed. Hashing is your home guard: the thing that will protect your passwords when everything else has failed. You hope that this will never be needed, but the cost of not having it when you need it is simply too high: multi-million-dollar lawsuits are only the beginning.


How to explain.

  • Humans are humans, it doesn't matter how modernized they are; there passwords will be something like Birth date or Name of the Girlfriend/Boyfriend/Pet animals etc etc.

So, it is a threat to save password in clear text. Anyone can read it.

  • Hashing helps to make them unreadable to humans (including loyal system administrator).

Once a password is hashed, it is practically impossible retrieve back. so, there is no fear that your password will be stolen by someone. Even if anybody get the hash, it is useless.

  • We can say, if password is a 'fruit' then it's hashing will be 'juice'. so, the juice is enough to verify the user password when he/she try to log-in.

Drawback of Password hashing is: No one can retrieve the original pass. In such a case, system must request user to enter New Password


  • 9
    Which, imo, isn't a drawback at all. This should be standard.
    – Martijn
    Commented Jul 18, 2014 at 13:27
  • I think there's no need for an analogy. Explain what really are the benefits of hash is the only way: It is easy to hash the password and see if any hash match. It is nearly impossible to use hash for find the password. And users are asked for password, not for hash. Commented Jul 18, 2014 at 16:05
  • @Martijn It's a drawback to the user. Commented Jul 18, 2014 at 17:09
  • 5
    I still disagree. It should become common knowledge that you can not retrieve your password, ever. That way, when you do get your password back, you should get worried.
    – Martijn
    Commented Jul 18, 2014 at 18:49
  • 2
    @BrianOrtiz Why would a user care if the password you give them is a new one or their old one? They clearly don't remember what it was before and don't have it stored anywhere, so for all they know the new password they just chose is identical to the old one.
    – Paul
    Commented Jul 21, 2014 at 0:48
  1. Explain that passwords get stolen all the time, and when it happens the companies are REALLY embarrassed and open to lawsuits if the passwords are in clear text.
  2. Explain that hashing is really easy to do today.
  3. Now for the analogy:

The best analogy of a one-way hash function to non-techies is just to just use a number look-up analogy - forget the complex cryptography. When a user originally gives you password, you assign a unique number to the password using a black box, and you store the number as the user's password instead of the original password.

When the user gives you a password again later for authentication, you pass the given password into the black box and get back a number. Now you can compare that number with the number you previously saved - if the two numbers match, the passwords are the same, if the two numbers do not match, the passwords are no the same.

Every unique password passed into the box gets it's own unique number, and each time the same password is passed into the black box the same number comes out.

The way the black box does the number look-up is very well known, and any problems with the black box are dealt with by the industry - any vulnerabilities are dealt with by the industry - YOUR company is not responsible if there is a problem with the black box.

Finally, if the number is stolen from the company database, the well-understood black box does not work in reverse - you cannot take a stolen number and get back the password (assuming that the original password was strong).


The most fundamental answer, which I haven't seen anyone state directly yet, is that the actions of anyone who would be in a position to discover a password cannot be reliably distinguished from the actions of its rightful owner. If one wants to be able to prove that the rightful owner either performed an action or by his own action exposed the password to an unauthorized person, then one must ensure that the rightful owner is never required to do anything that would allow anyone else to determine the password.

If Fred's password is stored in a database in a fashion that is not scrambled beyond recovery, then Fred could counter any allegation of wrongdoing by claiming that his password may have been used or leaked by someone with access to the password database. Unless specialized hardware is used to store passwords, there would be no way to disprove Fred's counter-claim.

Note that for real security, Fred should never expose his password to anything other than tamper-resistant equipment which he has reason to trust. Otherwise, there would be a risk that the equipment into which Fred types his password might be tampered with in such fashion as to leak the unhashed password to some adversary.

  • Yes, this is the most fundamental answer. However, this is not an analogy and not very useful in explaining to someone who already did not know.
    – emory
    Commented Jul 20, 2014 at 22:20
  • Perhaps my answer was a bit verbose, but the idea of "If your system administrator can access people's passwords, then any accusation of wrong-doing against anyone else will be a he-said she-said with the administrator" should be pretty understandable.
    – supercat
    Commented Jul 21, 2014 at 15:36

Imagine you're Scrooge McDuck. You've been keeping your piles of money in one giant vault for a while now, but there's a problem with that: if a thief ever gains access to the vault, all your money will be lost in one go! That's no good. So, clever duck that you are, you decide to split your money up into lots of smaller piles and put each one in its own separate vault. Now, if the thief ever gains access to one vault, only a small amount of your money will be lost, and you can easily replace the compromised vault. Much better! Except now you have a new problem: how to remember the combinations to all those different vaults? You can't just use the same combination for each one, because if the thief ever got their hands on it they'd have access to all your money and you'd be no better off than if you'd left it in one giant pile!

You decide to just write down all the combinations (along with the vault that each one goes to) on a little slip of paper, and then put that paper in its own, separate vault. Now you only have to remember one combination, but your money is still kept separate. This is an improvement, but it's still problematic, because if a thief ever did manage to find and crack the safe with the paper in it they'd still be able to take all your money. You don't want that to ever happen!

So what do you do? Well, the ideal solution would be to write the combinations down in some kind of code. You'd want a code that a thief can't use to get back all the original combinations, but that you can still use to get access to your money. Unfortunately, there isn't really a way to do this for money in vaults. Fortunately, it is possible for password-protected user accounts, because we don't actually need to know our user's passwords--we only need to know that they know them.

Keeping your money in one giant safe is like having a single master password for your entire system. Keeping money in different safes and writing down all the combinations is like keeping your users' data separate in password-protected accounts, but then keeping all their passwords in plaintext at a single location: as long as an attacker knows or can guess where that location is, it's not really any different than having a single master password. You need a way to encode your list of passwords in such a way that you can still use it to verify that a user has the correct password, while ensuring that an attacker can't use the list to get back the passwords themselves. In a nutshell, this is what hashing does.

  • Funnily, Scrooge's Money Bin is shown in some episode to have a trivial password.
    – Ángel
    Commented Jul 20, 2014 at 18:37

Let's say your database with passwords is leaked or stolen:

If passwords are in plain-text, all your password are belong to us.

If passwords are hashed, all passwords are still in a shared bank-vault that must be cracked.

If passwords are hashed and salted, each password is in its own private bank-vault.

  • Except that, when each password is its own vault, a weak password is a weak vault. With the "shared bank vault", at least the bank applies a high security standard to all passwords. The best thing is to apply both: then weak passwords have the common protection, and strong passwords have additional protection of their own.
    – Luc
    Commented Oct 13, 2018 at 11:52

Analogy time:

  1. Storing plaintext passwords is like leaving your house unlocked.
  2. Encrypting the password database is like storing the key under the doormat.
  3. Hashing passwords is like using a 3-digit number lock shared by all users.
  4. Salting the password hashes gives each user their own number lock.
  5. PBKDF gives those number locks more digits.

No one should actually decide security matters based on an analogy, but these might help explain to a layman why it is important to take precautions.


For hashing functions, no ready analogy finds itself in the sphere of football or automobiles. The best we can do is to spill the actual facts.

Dear Boss,

In a perfect world, users would be security conscious, and never use the same (or even a similar) password for two or more different sites or services. In that perfect world, a password would have little value to an attacker. After compromising the user database and learning the passwords, those passwords would not be useful for gaining access to other systems.

In the real world, users re-use passwords, and so the secrecy of passwords must continue to be guarded even when a system has been breached, in order to limit the damage.

Hashing helps to protect passwords, because the only way to obtain a password from the hash is a brute force computation which takes time. That computation will first break weak passwords which are short, or based on dictionary words and common phrases. It takes much longer to break strong passwords, but given enough time, those will fall too.

However, because it takes time to crack the hashed passwords, the users of the compromised system who tend to re-use passwords, or use similar passwords, will may have enough time to be warned and to change their passwords on other systems, before the attacker tries to access their accounts. (Those with very weak passwords will have little or no time, unfortunately, because weak passwords can "cracked" from hashes very quickly. The defense against are safeguards in the system which prevent users from using weak passwords.)

Without hashing, the attacker can immediately move on to accessing other systems after stealing the passwords from the compromised system. By the time the administrators even learn about the breach, other systems have already been accessed, at least for those users who re-use passwords.

There is a second threat: that of surreptitious access. This affects even those users who do not re-use passwords. Suppose that the password database of a system is leaked, but this event goes undetected. The attacker can use the passwords to surreptitiously access the system for months or years after the breach. Not only has the attacker stolen information which had been current at the time of the incident, but can continue to steal information simply by logging in to those accounts for which he has passwords, for as long as those passwords do not change.

Hashed passwords help guard against this threat, in particular when combined with a policy of regular password changes and strong passwords. Hashed passwords which are strong ensure that the attacker has to perform a lengthy computation in order to discover a password from the hash. The password change policy helps ensure that by the time this computation is done, the discovered password is probably useless because it has been changed.


Analogy: As a locksmith, I may (with the customers' permission) keep records of what I've done for them, including the details of their keys. But that puts me at risk of having my own shop broken into and the list stolen (or an Evil Employee doing so) -- in which case the crook could make keys for many houses, and I'd be liable for not having protected this information better.

The solution for keys is to NEVER store they key information in plaintext. Store it encrypted, and never write down the information needed to decode this data. If someone steals the encrypted list, they can't do any damage with it.

Of course, for a computer, "never writing down" would mean it couldn't decode the passwords. But we can solve that problem by creating a system where we don't actually have to decode them. Instead, we take the password the user typed, encode it, and compare the encoded version with the encoded password we stored. If they match, the user typed the right password. There are "codes" (cryptographic hashes) which allow encoding but not decoding, so this can be made respectably secure.

Hashed password lists can still sometimes be cracked, but it is TREMENDOUSLY more expensive to do so -- and as importantly, you can show that you made a reasonable effort to protect the users' data, so your liability is much less.


The technical importance of hashing is vastly overstated.

The practical reason you need to hash is because everyone else does it; it is considered "best practice". If you have a breach, it is much easier to defend a position where you are doing the same as your peers. Doing something different, even if it's the right thing, is much harder to defend. So I always advise websites to follow the standard hashing method, even though I think it's baloney.

So why is the importance of hashing vastly overstated? Lets start by thinking about a website with non-hashed passwords. The passwords would be stored in plaintext in the database. The database is secured - on a physically secure server, full disk encryption, firewalls, secure administration, and it is protected by the application logic on the web server. Those passwords are basically secure.

Why do we hash at all? It provides a last line of defence. Suppose all those defences where thwarted. Perhaps the NSA have used a zero-day browser exploit to get malware on the sys-admin's workstation, waited for him to login to the database, and from there taken remote control, and extracted all the data. In that case, the NSA gets all the plaintext passwords. And this is where hashing helps: if you use hashing, the NSA only gets the hashes, and they would have to conduct a brute force attack to get the passwords.

And that's why people recommend hashing. But this is flawed for three reasons:

  1. Personal data - the web site holds your passwords, and it also holds personal data. Whether it's messages, photos, shopping history. The reason you have a password in the first place is to protect your personal data. Hashing may protect the password, but it does nothing to protect your personal data.

  2. Live capture - while there are only hashes stored in the database, every time someone logs in, their password is sent to the web server. The NSA can silently sit on the server capturing everyone's password. Hashing does nothing to prevent this.

  3. Password reuse - It is important to avoid password reuse for other reasons. So, when LinkedIn is hacked, it hardly matters whether they get my password or not. The hackers already have my personal data from LinkedIn. And if they recover my password, it gets them access to LinkedIn only, and they already have that data.

Given all this, the benefits of password hashing are marginal. I don't know why the InfoSec community goes on and on about password hashing, it would be far more sensible to focus on preventing database breaches in the first place. In general, the costs of hashing are relatively low, but there is one exception: heavily iterated hashes. The technical cost of this is high, and the benefit is low, so this advice is quite badly misconstrued. Still, I have to advise people to follow it, because it is "best practice".

  • 3
    Wrong, wrong, wrong. The reason you have a password is to protect the ability to control your data. A database dump gives an attacker access to the information you have now. Plaintext login credentials give an attacker the ability to act on your behalf to change the data at will. Simply hashing a password isn't enough, however double-hashing is not unheard of (and the NSA's ability to sniff encrypted traffic is highly exaggerated). And you can tell people not to reuse passwords all you want; they still will, and it's still IT's fault if it was compromised.
    – KeithS
    Commented Jul 23, 2014 at 17:25
  • @KeithS - do you have data to back up your claim that most breaches are read-only breaches? You also don't seem to understand the difference between sniffing encrypted traffic, and sniffing locally from a compromised the host. Not that it surprises me, when your comment starts with three condescending words that belong in the playground.
    – paj28
    Commented Jul 23, 2014 at 18:42
  • You assert it yourself, that if the attacker gets a copy of the database, they have your personal data whether they have your credentials or not. The implication you seem to ignore about your own statement is that they'll make a copy of it on their own system to analyze offline. Without having someone's credentials already, or at least a really good idea, the initial data breach is always read-only; you either sniff the data stream or lift the data store, given sufficient time they're identical, then analyze the data for credentials to get in and cause real damage.
    – KeithS
    Commented Jul 23, 2014 at 18:49
  • And I do understand the difference between sniffing encrypted traffic and listening on a compromised host. That's why the news stories flying round of the NSA cracking encryption algorithms is overblown; that's not what they're doing. However, if the attacker has a physical or electronic presence at your computer, you lose. That's day 1. Most attackers don't have this kind of access, and so failing to protect stored passwords just because one government entity has the possibility to see them transmitted is like not locking your front door because locksmiths exist.
    – KeithS
    Commented Jul 23, 2014 at 18:55
  • @KeithS - Although details are hard to come by, I understand most breaches are due to a compromised database or app server and the attacker has read/write access. Read-only breaches, such as some SQLi, do happen, but are the rare case. A lot of the time, hackers are only interested in reading data (e.g. credit card numbers), although it's different for banking systems. Anyway, hash away, I'm not bothered, but I use high-entropy site-specific passwords (with a pw manager) so I don't care if you don't either.
    – paj28
    Commented Jul 23, 2014 at 19:01

What to tell the boss: "Here's the problem. I'm an experienced software developer and I'm telling you that storing unencrypted password is risky on a level of absolute inexcusable stupidity. Even storing unsalted passwords is risky on the level of gross incompetence. And I have just told you this. You can order me to store unencrypted passwords, and I will do it, but if we ever run into trouble I will tell anyone who wants to hear that it's not because I'm incompetent, but because you ordered me to do it against serious advice. At that point, I promise that you will be held personally responsible and you will have lawyers after you who want every single penny that you personally own.

  • 4
    This is more likely to get you reprimanded or fired than is is to get the point across and the problem solved. This would be a terribly dysfunctional approach.
    – Xander
    Commented Jul 18, 2014 at 23:43
  • 3
    Oh, and I should point out that it's also completely wrong. There is an approximately 0% chance that a middle manager would ever be held personally liable for data loss in a breach. Fired, perhaps. Not likely, but possible. Personally financially liable? Not a chance.
    – Xander
    Commented Jul 18, 2014 at 23:47
  • Well, where I live getting fired for this would get me a rather cosy settlement.
    – gnasher729
    Commented Jul 19, 2014 at 0:06
  • 1
    That is completely irrelevant. The question is about how to get a non-technical boss to understand the importance of password hashing. Not how to get a non-technical boss to fire you. This is a non-answer.
    – Xander
    Commented Jul 19, 2014 at 0:12
  • 1
    @gnasher729 where do you live? I have never heard of a jurisdiction where developers could not be fired for competence
    – emory
    Commented Jul 20, 2014 at 22:23

You must log in to answer this question.

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