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