13

Summary

The main reason for hashing passwords seems to be that users reuse passwords and, thus, leaked passwords would disclose sensitive information about a user (cf. this question.)

If the password is auto-generated and cannot be changed by a user, are there still good reasons for storing only the (salted) hash of a password?

Concrete example

I have two components which need to communicate, say, device A calls webservice B via HTTPS. To prevent some malicious actor from connecting to B and pretending to be A, A provides a password. I auto-generate a password and put it into the config files of A and B.

Now, A obviously needs the password in plain text, but B would only require the hash (since B can just hash the value received from A and compare it with the hash it has on file). Thus, my security-conscious gut feeling tells me that I should only store the hash in B's config file, but looking at the pros and cons, it is not so obvious:

Pros of storing only the hash on B:

  • In the unlikely case that B's config file gets compromised without B itself being compromised, an attacker can use the password to impersonate A. (If B itself is compromised, the attacker obviously does not need the password any more.)

Cons of storing only the hash on B:

  • If A breaks and needs to be replaced, I need to change the hash on B because I don't have the original password any more. (Alternatively, I need to have my client, on whose premise A and B run, securely store the password, which they probably won't do. Alternatively, I need to store the password securely somewhere, which is additional work and liability risk for myself.)

Any other pros/cons that I missed?

Heinzi
  • 2,914
  • 2
  • 21
  • 25
  • It's a bit offtopic to the core question, but the best practice way to have device A authenticate to webservice B would be not with passwords but with TLS/HTTPS client certificates, which behave a bit better in various edge cases than what you describe; and in your proposal, it might be more accurate to call the "thing" that you describe as a *bearer-token* instead of a password or hash of it. – Peteris May 29 '20 at 20:30

1 Answers1

27

The main reason for hashing passwords seems to be that users reuse passwords and, thus, leaked passwords would disclose sensitive information about a user

This is an incorrect statement. The main reason for hashing is to protect passwords from disclosure in case an attacker has got access to the database (access to the database directly or to its backup). It does not matter if the password was created by the user or generated by some tool.

You are right that weak passwords can be "improved" by hashing. But hashing cannot really make a weak password secure. E.g. if an attacker takes a database with 100 000 of weak passwords, he/she can test all of them easily despite using "resource expensive" hashing like Argon2. That's why hashing should not replace the check of password quality. If the user changes the password, the password should be validated to ensure sufficient complexity (length, randomness). This is equally applicable to passwords of real users and for passwords of "technical" users like your "device A".

In my opinion, generating a hash (in case the password for device A needs to be updated/replaced) is pretty easy. And this should be done not only in an emergency case when A was compromised, but it should be done regularly, e.g. once a month or once every 3 months. The admins should have a tool for it. So that updating a password takes a few seconds. That's why I don't see any disadvantages with it.

TLDR: There are no real disadvantages, there are only advantages.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/108705/discussion-on-answer-by-mentallurg-what-are-the-risks-of-not-hashing-auto-genera). – Rory Alsop May 31 '20 at 12:07