Is Password Hashing Bad?

Question

In software design and security, why would it not be a good idea for users to send you their passwords and it would be a better idea to delegate: use public-key auth or logging in with one of these: OpenID connect, "sign in with Google" or "Facebook", etc.

I am curious to understand more about these topics. I recently moved from a very large tech company to a much smaller one, and in my current company, they have a practice of storing user passwords in a database. They salt and hash the passwords, but I think that trying to manage security and cryptography themselves is biting off more than they can chew. In my research, I found this (source: Stanford University) and wondered if this community had any thoughts about the claims made here (this is a little dated..."Facebook" for example is mentioned, although I wondered if these recommendations are still relevant today).

For clarity, this is from a lecture entitled, "Bad (Attitude) Guide to Computer Security". So it is likely that the author is making these big claims with a kind of playfulness. I'm asking the question here to better understand the actual concepts and the seriousness of the claim (along the lines of, "is this a total joke that shouldn't be taken seriously at all, or is there actually a good lesson in this advice?")

Password hashing is bad.

• Password hashing is bad because it makes you think it's okay for users to send you their passwords.
• Users should not send you their passwords.
• Your site security should not depend on your enforcement of a password complexity requirement.
• You do not want a server compromise to expose anything that allows a bad guy to intercept or crack user passwords.
• Better: Delegate. Use public-key auth, or "Log in with Google" / "Log in with Facebook" / OpenID Connect.

^{Screenshot of the lecture slide}

Source: https://cs144.github.io/handouts/Winstein-Bad-Attitude-Guide-8April2016.pdf

Answer 1

This is a reasonable point being justified using incorrect claims.

The issue here isn't about having users enter passwords. How do you think they're going to log in to Google/Facebook/any other third party identity provider? Right, by using a password (and possibly other factors on top - but the primary private key being used is a password).

The point of this advice isn't that passwords are bad. The point of the advice is that everyone rolling their own password system is inefficient as not everyone is investing in the same kind of security or reliability. Instead, it's better to delegate identity management to services that are dedicated to the job, which is what third party identity providers are.

The advice is essentially the same as saying that it's better for everyone to call the expert plumber instead of trying to do their own plumbing. With that advice, I agree.

I disagree about all the bullet points before it. Not because they're not true, but because it's implying that the issue lies with the concept of passwords; which is not what the conclusion of the advice supports. The title of the posted screenshot is just plain wrong.

Answer 2

The specific claim: "Password hashing is bad" is somewhat odd. If you are supporting passwords, hashing is pretty important. The more interesting and more contentious (based on the other comments and answers) question is whether passwords are bad. I'll come back to that but for the moment, let's assume it's the case that passwords are 'bad'. That's a bit like saying that drugs to treat opiate overdoses are bad because they allow people to survive overdoses. If you are using passwords, hashing is crucial and you need to be sure you get it right.

With regard to passwords: they aren't a great security solution. This shouldn't really be news to anyone at this point. The key problem with passwords is that they require sharing a secret. It's much preferable to use a solution where no secrets are ever shared e.g.: using public key cryptography. In practice, it's usually MFA: something you know (password) and something you have (a device.) When I login to my VPN at work it's a password, client-cert, and an authentication app on my phone.

Where do 3rd-party providers fit into this? The biggest benefit, I think, is what you are concerned about. These providers make it their business to manage security. One of the challenges with hashing is that what it considered secure changes over time. Is there someone at your employer whose job is to stay on top of password hashing standards? If not, then it's probably a risk that they are managing this internally. A 3rd-party identity provider can likely manage that better and should allow you to upgrade to MFA with no additional effort.

My experience with 3rd-party identity providers hasn't been completely smooth. The really big well-known company we use can't get it together to document things right, so we had to scour personal blogs and SE to find the secret recipe that we would never have guessed. It can be frustrating because you usually don't get a lot of helpful error messages in this space (for security reasons, I suppose.) But after the initial pain of implementation, it is pretty simple compared to the challenge of securing password hashes properly over the long term.

Addendum

While the question kind of implies that the only option is to use something like Google or Facebook identity providers, it's probably good to know that there are many other ways to configure such schemes. For example, you can use a 3rd-party to manage authentication while retaining ownership and control over it. This might mean you simply have a Saas solution managing that authentication. The point isn't just that someone else will manage password hashing better (they probably will) but that also are likely far better positioned to incorporate more sophisticated solutions beyond passwords.

Answer 3

I would agree in a kind of "if life were perfect" sense. If you rely on Google, FB or whatever and you can force that option on every one of your users, you never ever can be held responsible for password leaks. Theft of a user's credentials might cause you downstream problems, but the breech itself will never be from your site and will never be your fault.

In B2B applications, offloading identity (and authorisation) is even more useful. If you can use federated identity with your customers' identity providers then you also push away user access reviews (who still works at the company, in what role) as well as credential security.

If you use well tested, supported 3rd party/open-source libraries you save yourself a lot of code and vulnerability, so I would totally advocate for this approach.

Sadly, I have never actually been part of an implementation that can mandate 3rd party/federation. Every single system, either due to age or due to management reluctance to excluding some users, has had to manage username & passwords onsite in addition to delegation, which is a real shame.

I guess the answer I would give is that password hashing in itself is not inherently bad, but avoiding password management altogether is significantly better.

Answer 4

In looking at this slide we should probably evaluate it against two scenario's:

1. An average user with weak security (password re-use, dictionary passwords, no 2FA).
2. A more security competent user (Password Manager, no-reuse, 2FA, rotation ...)

For the first class of user (where the password they send you is crackable and/or has been used on multiple sites) it is probably better to simply delegate the problem (user) to one of the big social networks and let them handle it.

For the second case the password/MFA pair is just a couple of shared secrets ideally neither should be used to secure any other site, so a breach of your site "only" exposes the data you hold.

With modern password managers which also store 2FA secrets, the "what you know, what you have" has really morphed to using "what you know" to unlock the password manager and depending on the password manager potentially "what you have" being the device where the password manager has been installed/configured (with an additional secret).

Answer 5

The lecture is an interesting one. He does indeed make some bold claims, like "Roll your own crypto," citing one of the gems (Mosh) that got it right... or apparently got it right. Never mind the odd quirks, like needing to open up a block of 1000 ports and ensuring that none of your other insecure apps use those ports...

But as to the password security question in particular, I'd point out that a password is more than just something to hash. If it were, then the oauth2 tokens you receive when you use a third party login tool would be just as nefarious. Practically speaking there are other concerns.

• Users often reuse passwords. If they do, the password is more valuable than just a way to log into your site. We do not live in a world where we can trust users to come up with good passwords all the time
  • Using third party api keys is basically a guarantee that all of your users use strong authentication secrets - stronger than the average password
• Passwords often need to be reset. This requires a reset mechanism which is an increased attack surface.
• Large players can afford to do things like 2 factor authentication. This may be outside of your budget.

Personally, I'd take what he says with a grain of salt, but what I think is a useful takeaway from this is that a password is more than just a shared secret. It comes with additional baggage that must be accounted for.

Answer 6

No, password hashing is not bad. It is a better way to protect user privacy.

Big corporations tried to impose single sign on for a long time. It started at the end of the '90s with Microsoft Passport which at the time failed, but was rebranded several times. Centralised sign on is an effective way to track user activity. Note that it is not necessary for the sign on provider to know what the user is doing after login. A list of all the services used by each user is already enough to provide useful metadata. A lot of big data analysis currently is done using only metadata because using detailed data often leads to exponential complexity. However metadata already provides a lot of useful information.

Some users may not care about their privacy, but already a lot of internet sites offer the choice to login via a centralised ID provider or not. The users who choose to use a local account are those who care more for their privacy. Forcing them to provide their private details to a centralised ID provider is a bad idea.

The:

Password hashing is bad.

rules you posted are malicious. Sending the password to a local of a centralised server from a security point of view changes nothing. Beyond that the simple concept of hashing is the safest way to handel the passwords.

BTW The source document you posted does not match the content of the question.

Answer 7

Password hashing is an attempt to defend against a particular attack, specifically the case where an attacker gets their hands on your password database.

But there are a couple of problems.

1. Server side password hashing, doesn't stop passwords being captured "in-flight". If someone has hacked your server to the point they can steal your password database, there is a good change they are also in a position to install a password logger. Client side hashing has it's own issues (like preventing the hash from becoming a password-equivalent).
2. Password hashing only helps if the password has enough entropy that cracking the hash is hard. Many passwords are not strong enough for that.

From a point of view of protecting passwords from compromise it's much better to have an "authentication service" such that the applications never even see the password. Especially considering that however much you tell users to use different passwords for different services, many of them won't.

However, protecting passwords from compromise isn't the only consideration. If you rely on a third party authentication service, that service becomes an availability risk.

Answer 8

There are many mantras of the form "If you need to deal with X, you're probably doing something wrong". One "X" to which this applies is "the precise computations used to hash passwords".

The issue here isn't that X is bad, but rather that most tasks that could be accomplished in ways that involve dealing X can also be accomplished in better ways that allow the programmer to ignore X.

If one is performing tasks that genuinely can't be done without low-level password hashing calculations, then one should perform such calculations. Before diving into the design of code to perform such calculations, however, it's a good idea to consider whether the task at hand could be better accomplished some other way.

If one needs to cut some things, the number of situations where one could use an axe vastly exceeds the number of situations where the axe would be the "right tool for the job". That isn't to say that an axe is a bad tool, or that people who use axes to split logs should be viewed with suspicion, but people who need to cut a path through jungle folliage or cut circuit board traces would be better served with machetes and scalpels, respectively.