A friend of mine is puzzled because she called Weight Watcher online when she was having trouble setting something up, and the CSR said something like, “Okay, let me log you in,” and says my friend’s login name as she enters it, then, “and I’ll enter your password, ‘xxxxxxx,’” and said the correct password as she enters it.
Can online CSRs generally see passwords for the online accounts they service?
Now we’re wondering who can see the passwords that are stored online? I’d be surprised if CSRs can generally see them. Clearly, this one could. I seem to remember calling some places for help (like Sprint maybe?) and being asked for my password, so presumably the CSR was verifying it.
Maybe there’s a difference between sales support and tech support when it comes to who can see your password?
Generally no. Passwords ought to be stored in such a way that nobody other than the account owner can know what it is.
If they’re storing passwords in cleartext, and it sounds like they are, it’s a major security failure. It will bite them one day, and they’ll deserve it.
I used software for my small business once that allowed my CSRs to see our customer’s passwords in plain text. I hated it, and I forbid my reps to use the password under any circumstances - people reuse passwords and anyone would feel legitimately nervous if some random CSR could see it.
However, we were a small business and it was great software aside from that. I couldn’t customize it to disable that or go with different software purely because of that.
So in short, you really have no way of knowing but it’s not a good practice to do that for many reasons. I wouldn’t imagine it’s common.
Some systems let administrators log on to a persons account with knowing the password; that’s convenient for troubleshooting. A couple of thing I administer have this feature, but I can’t see any passwords in our setup.
The system as you describe would give any Internet security expert a heart attack. The password should only be seen by the user; viewing an account can be done without it in any properly designed system.
Good software doesn’t store passwords. It should be storing a hashed version of the password that can only be used to verify if you’ve entered it correctly. No CSR can display the password if it’s not stored, and that’s where the security failure occurs.
Usually the passwords are stored in MD5 or SHA hashed format. However, there are reverse hash rainbow tables available and if the password is weak, an attacker could derive if from the hash value
In the OP’s case, obviously, they could (unless something between the CSR->friend->OP got misheard). On most, like mine, they can’t, but they don’t need a password, just the person’s name or login to work on their account.
I work in banking and am involved in the design of our online banking customer servicing tools, and can say definitely not for my company. Not only can we not see the one you have, we also can’t set a new one for you. Best we can do is help you in doing it yourself.
Speaking of them seeing your passwords- when I go to change the password for my cable account, it tells me not to use “undesirable words or phrases”. WTF is it to them?
First, it will bite all the customers/members, who won’t deserve it at all, when they find their identities stolen or their bank/credit/whatever accounts hacked and plundered. Then, when it gets traced back to the company, it will bite them.
Perhaps they have or had a system where you may have to say the password out loud to an employee at some point.
Don’t want granny down at the cable company having a heart attack just because your password is BUTTMASTERLEATHER500 or something.
That’s silly. Yes, MD5 is considered broken. But the best known preimage attack on the hash still has a complexity over 2^120, and therefore nowhere close to practical yet.
Cryptographic applications sensitive to collisions and not just preimage attacks are definitely more vulnerable to MD5’s weaknesses, and there are viruses in the wild which exploit this. Nevertheless, the attacks are sophisticated, and so saying that MD5 is just as bad as plaintext is absurd.
That’s not the reason why it’s a bad idea for password hashes. MD5 is a message digest algorithm which is specifically designed to be fast. That’s great if you’re doing error checking; it is a very bad idea for situations that are subject to dictionary attack.
And the available dictionary databases for MD5 hashes are gigantic. Try downloading one and run your MD5 passwords through it; even if they’re salted I bet you get a bunch of hits. Generating MD5 dictionaries is just too easy.
Fast hashing is a positive property of any algorithm. If you want it to be slow for security reasons, you can always iterate the hash. No one writes an* intentionally slow* hash (although slowness might be the cost of a secure hash).
Well, rainbow tables are certainly easily available. But finding common passwords in those DBs just means your salt isn’t long enough. Nothing to do with MD5 here.
FWIW, I tried Googling MD5 hashes generated by appending “password” with various length hex strings. It only found a hit when I got to a 3-digit salt. As it turns out, that’s the same length (12 bits) as the original Unix salts. So yeah, salting standards from the 1970’s are considered broken :).
Maybe one day I’ll download one of those multi-terabyte rainbow tables available via BitTorrent…
I’ve worked for a few companies where passwords for specific applications were stored in plain text. We tended to avoid those applications like the plague.
