Convincing my manager to use salts

Question

My manager says we don't need to salt our passwords because people are not likely to use the same password because they all have different native languages, in addition to the websites they are active at. What is the best counter argument to this?

Answer 1

I'm not sure where you are from. First of all his opinion is against the the considered industry best practice as defined by NIST. Furthermore your manager is dangerously wrong. The more users the more likely it is to get the same passwords for several users. Also the following companies do it and I'm quite convinced that they have a larger global user base than your website:

• Facebook
• Gmail
• Linkedin

Also another reason which is something you can explain from a business perspective is the risk of image/brand damage when you get negative publicity. To give you an example Adobe used a bad implementation for password storage which lead to the same issue as you are having now: the value resulting from hashing (in case of Adobe they were using encryption rather than hashing) the password was the same for several users if they were using the same password (in their case due to not using an IV while performing symmetric encryption, but this is not relevant). This caused a massive storm of negative publicity, after all an internet company should be adhering to something as simple as password hashing no? The financial cost resulting from such negative publicity can be significant.

Also depending on the country where you live and the laws employed, these days the management can be held personally accountable if it is determined that they were negligent when it comes to protecting data privacy (if cracked passwords are used to get personal data of users for instance). Also depending on the type of information stored, financial, medical, credit cards, different rules may apply which can result in other types of fines as well.

This is something which might not be relevant for password hashing directly, but might come in handy if your manager makes further bad decisions. So make sure to make copies of emails where you clearly explain the problem and also save your managers reply. (just to cover your own ass)

The fact that you are not using salts also probably means you are not using a correct hashing algorithm, as these often take care of the generating salts and performing an amount of iterations. The three accepted algorithms are:

• PBKDF2
• bcrypt
• scrypt

Answer 2

The main purpose of salts is to prevent an attacker from saving work by comparing a single calculated hash with all stored hashes. This problem is independent from whether or not the passwords are unique.

Without salts, the attacker can simply go through his list of possible passwords, calculate the hash for each one and then check if the result matches any of the stored hashes. So only one calculation per guess is required.

With salts, the attacker must go through his list for each user, because he cannot reuse the results. This forces him to do one calculation per guess and per user. This massively increases the costs of the attack.

But as Lucas already said, the real problem here is that you're not using a proper algorithm. Salts are only one aspect of password hashing.

Answer 3

The "best" counter-argument depends on what you are trying to achieve.

If you just want to be scientifically right, then it suffices to say that salts are not, and never have been, a method to cope with two distinct users choosing the same password. In particular because two users who happen to choose the same password is not a problem to begin with, so there is nothing to fix. Salts are for avoiding parallel attacks, including use of precomputed tables. Lack of salts was the capital sin of LinkedIn.

Now being right has an effect only on people who are ready to acknowledge that they may be wrong or at least incompletely informed. What you quote from your manager tends to demonstrate that he is both completely incompetent on the subject, and also convinced that he totally masters it. If you want to convince that manager that he is wrong, then, fat luck on that. What people fear most is admitting, even implicitly, that they said something stupid.

If you want your organization to actually switch to proper password hashing (read this), then what you might be able to do is to convince other people that what the manager just said is pure gibberish, that it does not even make enough sense to be actually wrong. If the manager becomes isolated, he may turn a blind eye on the implementation of proper password hashing, without, of course, ever acknowledging it. There again, the scientifically correct argument is not necessarily the most efficient one. In North America (especially British-influenced areas like New England), business meetings are about avoiding clashes and diluting responsibility, so you should spread some fear, uncertainty and doubt: be sure to point out that your competitors are switching to salted hashes, and not doing the same incurs the risk of losing some market share. In southern Europe, meetings are ritual battles to establish hierarchy, so shout, growl, threaten and use sarcasm to win the crowd support: you don't win by being right, but by being assertive.

---

One of the most efficient types of arguments, generally speaking, is the appeal to authority. In NIST Special Publication SP800-118 (currently in draft), one can see:

Another example of a hash algorithm weakness is that some algorithms do not use salting.

"No salt" = "weakness". NIST says that. Who is this manager who thinks he is smarter than NIST ?

Answer 4

In a certain sense, if you're arguing about salt then you've already missed the boat. The state of the art with respect to password storage security is well beyond the "to salt or not to salt" question, and has since moved on to counting iterations.

But lets start with basics. Here's an answer I wrote a short while ago that was surprisingly popular. It explains why salt is better, and lots of people have said it made something click where other explanations fell flat. It's more or less what you're asking -- show it to your boss if you think it'll do some good:

Why are salted hashes more secure?

But the important point there is the last one made there. That is, storing a salted SHA1 hash and calling it good is no longer considered responsible. Computing power has hit the point where billions of hashes per second is no longer theoretical, allowing you to blow through the entire 32-bit space of a brute-force attack faster than what it would take to explain what you're doing.

Now the focus is on forcing the attacker to solve the problem thousands or hundreds of thousands of times just to make one guess. That's where PBKDF2 shows up (wearing its NIST-issued suit and tie), as well as scrypt and friends (looking scruffy but powerful).

Which algorithm you choose isn't really the key. They all solve roughly the same problem, just in different ways with different emphases. But you have to use something -- some algorithm that makes it difficult to brute-force even a single password. The reason is simple: It's the industry standard, it's measurably and provably more secure, and there's no significant cost to using it. Put those factors together and it quickly becomes apparent that if you don't do it, then you can be considered negligent in the event of a breach.

Answer 5

The best argument is to pull out a list of the most common passwords and show that about 1% of your users will pick "123456". The second-best would be to pull out a password leak analysis for a large site and show that only about half of your users will manage to come up with a unique password.

Answer 6

You should make two points:

• Using a salt reduces the value of a stolen file containing hashed passwords. This is true regardless of what language(s) are spoken by the users of the system, because an attacker who has a rainbow table for your hashing algorithm can use it to reverse the hashed password irrespective of the native language of the person who chose that password.

• Using a salt is almost free. It gains you almost nothing to exclude it, and even in your manager's current estimation excluding it is only "likely" to not cause a serious security problem. Therefore, use it.

There is an objection that your manager might raise against the first point, but I hope cannot: "we are using our own custom hashing algorithm, so there is no danger that a rainbow table exists for it". In that case, you must also make the case for using a standard password-hashing algorithm.

I also find:

[the users] all have different native languages

to be a bizarre assumption to make about a system. If you rely on an assumption for your security analysis, then your system becomes insecure (or at any rate, not assessed for security) as soon as the assumption is broken. So having relied on this assumption for security, you then need to enforce that no two users of the product have the same native language. Why on earth would anyone want to restrict their system in that way, and in particular how is enforcing this restriction going to be easier than using a salt?

However, in this case that assumption doesn't even lead to the conclusion your manager makes that salt is unnecessary (for the reason I give above). So the question of whether the assumption can be maintained is fairly irrelevant in the face of the fact that it doesn't help!

Finally FYI, there's a specific reason why my first point above contradicts your manager's analysis:

not likely to use the same password

is a flawed analysis of the weakness that salt addresses. It doesn't matter to the attacker whether two users of the system have the same password or not, unless the attacker just so happens to be one of those two users and therefore knows the password that they share. Salts do not only defend against this attack, they also defend against rainbow table attacks. So even if this unusual same-password attack by one of your users were impossible on your system, you would still need salts.

Answer 7

I guess this is more a people problem than a technical issue. Therefore you need to respond with soft skills rather than technical explanations. If your manager reacts positively on technical explanations, choose one of the answers before.

If you want to go the soft skills side, you can try a few things:

• Most important to remember: your boss is your boss. Do not get angry against him, otherwise you'll be the unlucky.
• Try not to ask him questions which he can't answer. Instead ask indirect questions in form of simple sentences.
• Try understanding his standpoint and arguments.
• Apply paraphrasing.
• Never laugh.
• Never be impolite.
• Read Dale Carnegie's book "How to win friends and influence people".

A sample dialog might look like this (be aware that I'm not a native English speaker):

Boss: "We don't need salts."
You: "We don't need that additional protection."
Boss: "Yes, our users don't reuse the same password."
You: "Strong password are already secure."
Boss: "That's right."
You: "Alright, I understand. Our users make the password secure and we just live without salts."
Boss: "Yeah, maybe not all users ..."
You: smile

Or like this:

Boss: "We don't need salts."
You: "The benefit of using salts is not worth the effort."
Boss: "That's correct."
You: "So we deleting the salt from the task list and go on with the rest."
Boss: "Right, we're already behind schedule."
You: "If we would meet the schedule another way, can we would implement the salt."
Boss: "No, I don't understand that salt concept."
You: "That cryptographic stuff is always hard to understand."
Boss: "Even when I read an article, I didn't get the clue."
You: "Which makes you think it's a lot of effort."
Boss: "Yes, we'll lose two days or so."
You: "With some help of a framework I can do it in 2 hours."
Boss: "Really?"
You: smile

Note that there are no question marks at all. The boss is never under pressure of answering a questions which he might not know the answer to.

Unfortunately it's quite hard to apply such techniques if you never did before.

If this approach doesn't work well either, there's one more option:

Just implement it. It shouldn't be too much effort and your boss will probably not notice it, except he's doing code review or looking at database tables.

Answer 8

Just throw some hashs (maybe his own password) into Google. Most likely it will return the password. His weak hashing is like no hashing at all.

https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

If that does not convince him look for a new job...