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?
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?