Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation.
[1] http://www.troyhunt.com/2012/07/lessons-in-website-security-...
I have absolutely no expectation that it is going to be fixed either.
That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.
[0] And possibly normalise their length/character set, something that comes for free with hashes.
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.
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.
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.
Never design for what people are supposed to do. Design for what people actually do.
Thanks.
If someone has read-only access to the database (e.g. a junior developer) they can do absolutely nothing with a hashed password