Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4?
[0] And possibly normalise their length/character set, something that comes for free with hashes.
Firstly, an attacker with access to your backend database will have full access to user credentials if passwords are not salted and hashed. An attacker can then sign in as any user. The attacker may not be trying to steal all your have and may instead be looking to make life difficult for a single specific user.
Secondly, users will reuse passwords. An attacker with access to the plaintext password and the user's email address can use this to try to gain access to other services.
Thirdly, the attacker in the first example could be a disgruntled employee. You don't want a disgruntled employee causing trouble.
Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen.
I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user.
However,
> Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen.
sounds odd, since the user transmitted their password in clear text to the server at least once when registering, unless you use browser-side hashing/salting, in which case this hash would then take on the role of a password (i.e. wouldn’t help at all). Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.
> Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.
With a salt, it removes all doubt.
If an employee has a grudge against one customer, they could take the unsalted pass, and authenticate as that customer, no database transactions; essentially no paper trail.
If that scenario happened on a hashed and salted database, you'd have transactions that X employee changed the salt & hash, then 20 minutes later changed it back. As soon as (CEO/CTO/Mr. Manager) finds that out, X employee is held accountable for their actions.
" given that someone with access to the backend database could probably effect queries ‘simulating’ an active user."
Yes, in shortsightedland. In a company where storing plaintext passwords is normal, it's not too far fetched to think that they are probably backing up and restoring their databases all over the shop.
They only need to lose a laptop on public transport and now they've basically distributed ALL their users common passwords.
Probably the same reason civil engineers design every individual component several times stronger than they need to be. Redundant safety points mean multiple things have to simultaneously fail instead of just one thing.
[0] And possibly normalise their length/character set, something that comes for free with hashes.