views:

58

answers:

4

Possible Duplicate:
Encrypting/Hashing plain text passwords in database

Recently, I discovered that major web hosting companies store their users' passwords in plaintext and even ask for the last 4 digits of the user' password when trying to verify their identity. This seems vitally wrong and full of security problems. I believe their reason for doing this is to simply help in identifying users.

  1. What is the correct way to securely store users' passwords? And what is the correct way to safely and securely identify users, without asking for their passwords (e.g. over the phone)?
  2. After Googling for a little bit, it seems that many people have complained that several popular web hosting providers use the plaintext method. Can it really be true that that many web hosting providers use this plaintext method of storing passwords? What are some popular web hosts that do securely and safely store their users' personal information?
A: 

You generally don't want to store the password at all -- you store a hash of the salted password. When they want to log in you salt and hash what they supply as the password, and compare the result to the stored hash.

Jerry Coffin
A: 

Addressing the first part of your questions: Do not store the password at all. Store a hash of the password, salted.

For recognizing them over the phone, I'd probably have them first verify a phone number in advance, and then use that in combination with a secret question they can define.

Many hosts don't securely store passwords, sadly. I don't have enough experience to comment on good hosts in that regard.

Daenyth
+1  A: 

Regarding #1 - The correct way to do it is to not store the passwords at all. Instead, store a salted hash of the password.

As for safely identifying users without asking for their passwords, that's a bit of an intractable problem. Anything you might use to identify them in essence becomes another password (with the same storage problems as the first one). Practically speaking, most services would use some other bit of personal information - last 4 digits of soc. sec. number, mothers maiden name, or a "security question". All of these are almost certainly less secure than a good password though.

Eric Petroelje
+1  A: 

1a) Don't store the user's password, only a (salted) hash of it. When a user logs in, hash the password they provide and compare it against your archived hash. If you don't know the user's real password, you can't compromise its security.

1b) It's difficult to securely identify a user over the phone, and the level of effort you'll make will depend on how "dangerous" unauthorized access to the account would be. My bank accounts require me to call from my home, work, or cell numbers (which I have listed with them in advance). You can ask the caller to verify randomly-selected pieces of account information that you have on file (like account number, billing zipcode, middle initial, date of birth, the seventh digit in the credit card number, etc). Some phone-based systems have a per-user PIN number that is different from the normal password/PIN. You can send the caller a one-time passcode to their mobile phone via text message, and require them to enter it into the system within some time limit. One of the more secure systems I've seen uses Verisign's VIP Mobile app to generate one-time passcodes. (of course if someone steals your mobile phone, it doesn't help much)

2) I doubt that information is publicly available. If there was a list of companies that insecurely store user account info, it would double as a "please hack me" list and those companies would get slammed by intrusion attempts.

bta