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?
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.
But let's start with that. Say you store your users' passwords like this:
# id:user:password
1:alice:pizza
2:bob:passw0rd
3:carol:baseball
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.
Instead of storing the password, we store a hash of the password. Your database now looks like this:
# id:user:sha1
1:alice:1f6ccd2be75f1cc94a22a773eea8f8aeb5c68217
2:bob:7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53
3:carol:a2c901c8c6dea98958c219f6f2d038c44dc5d362
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.
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.
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.
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.
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.
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.
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.
hashing the password (is) a giant hurdle (which is typically why I don't like analogies)
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.
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.]
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.
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.
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.
So, it is a threat to save password in clear text. Anyone can read it.
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.
Drawback of Password hashing is: No one can retrieve the original pass. In such a case, system must request user to enter New Password
.
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.
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.
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.
Analogy time:
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:
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.
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.
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".
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.
