emailing passwords

[distorto]

I'm building a "forgot password" portion of a site and I'm wondering how others have done this. I have always been annoyed by sites that force you to select a new password every time you forget yours. It always leads to this perpetual cycle of forgetting the password due to endlessly changing it and always forgetting to write it down.
I really like sites that actually email your password and let you log in as usual (webmasterworld does it this way!)
this implies that the actual password is stored somewhere, since the hashing algorithms I'm aware of are one way. is there a special security measure taken when the actual password is stored on the database?

[coopster]

If the content on the web site is indeed worth protecting, then an encrypted password and encrypted logins are a must. Why send a secured password via open protocol like email? If the site merely requires some form of authentication and the data and/or service is not terribly critical, then an open password solution may very well fit the bill. You can bet if WebmasterWorld was providing medical information, you would never see the password stored in plain text and never, never sent over an unsecured protocol!

[PHP_Chimp]

A simple way to protect a password in a database is to use the good old md5($password).
You are correct that md5 is (sort of, if you dont dig to hard) 1 way. But you can still use something like -

//$_POST['enter'] = user supplied password
//get password from database
$db_password = $result['password']; // this was stored as the md5 hash of the original password
if (md5($_POST['enter']) == $db_password) {
// let them in
}
else {
print "Try again\n";
}

So this way you are only storing an 'encrypted' version of the password. You are still sending unencrypted passwords over HTTP so these can easily be grabbed, however HTTPS will encrypt the traffic.
If you choose to store passwords in plain text then you should have rock solid server security (bearing in mind that everyone makes mistakes, so this will never happen). As many people use the same password for almost everything.
So there log in to a social networking site may be 'help123me_2', they also use that for there bank password and many others. Someone breaks in to your server and you have just potentially given out everyones bank password. If you want to be able to retrieve the original password then use the mcrypt [uk3.php.net] function and actually perform a 2 way encryption on it.

The other option is if someone looses there password you email then a temporary password. They can then use this to log back in and change there password to whatever they want. then you can still store passwords in 'encrypted' format. You are still back to the old problem with sending passwords over an unencrypted channel, but you could do it all in the browser and use HTTPS to keep it encrypted.

[eelixduppy]

Just for reference, PHP_Chimp, with md5, although it is "one way", there are ways to reverse it. The best approach is to seed the password:

$seed = 'abcdef1234';
$encypted = md5($seed . md5($seed . $password));

[distorto]

I am not storing any critical information like medical records or bank account numbers. I'd still like to make things as secure as possible, but convenience and ease-of-use is a large consideration for this site.

my initial idea when I found out that they want the password emailed was to store the password in 2 places. One place would store a hash - this is the one that would be used for login/logoff comparisons. I was thinking I could store the actual password string in a separate location only accessed when the user forgets the password. I guess I was checking to see if there's a clear methodology to this method of password retrieval, as it's the one used here.

[PHP_Chimp]

I know that md5 is reversible...

You are correct that md5 is (sort of, if you dont dig to hard) 1 way.

Next time I will spell it out in plain English.

That is why encryption is mentioned in inverted commas, as even the true encryption is only relative. All it takes it time and you can break anything. There are ways to slow down this cracking, however for the vast majority of people md5 is one way. It also has the added benefit that almost everyone uses md5, so when your server is compromised and it ends up in court your defense is that md5 is an 'industry standard'. Like AES is for 'proper' encryption.

However your solution of double hashing with a small additional string is only going to increase the security of that password minutely.
The use of SHA1 will increase security over md5, however SHA1 has been cracked as well.
A much larger (greater than 32 characters) random alphanumeric string with additional punctuation characters would increase security a little more.

However it is all relative to the price the data you are holding is worth.

The user comments in the php md5 [uk3.php.net] manual page should give an idea as to how secure md5 actually is.

But hey if we are being pessimistic about security then how many people use ftp to upload there scripts/pages to there website? Ftp isnt secure so all of those ftp passwords and mysql passwords that have been sent, in plain text, across an unsecured protocol... Humm just be glad that no one has picked them up yet....or have they and you dont know it?

distorto -
My point about passwords is that although you may not hold that sort of information people use the same password for everything. So the password you hold may well be the same as there bank password, you just dont know. So you cant say that because you dont hold secret information that you dont need to worry so much about security.

[edited by: eelixduppy at 9:33 pm (utc) on Jan. 3, 2008]
[edit reason] removed url [/edit]

[eelixduppy]

Storing passwords in two places potentially has the same security risks as storing it in one location--as long as one version is stored as plain text, that is. To be as secure as possible you'd want to store it encrypted and ask for a security question to reset the password; maybe you could also verify an email address. It really shouldn't be that much of a problem for a user. I don't know about you, but if I cannot remember my password and I request it through email, I wind up resetting it to something I would remember better, anyway; why not get it over with while remaining more secure?

>> double hashing with a small additional string is only going to increase the security of that password minutely.

The additional seeding string adds an extra security layer that makes an attacker have to guess to do anything meaningful with the hash. Any extra security, no matter how small, is better than not having it. A straight-up md5 hash can be decrypted as you know, very easily; it's not as easy with the seed.

btw...I tend to skim through most threads that I read due to time constraints and the quantity of posts I read. I missed your comment about knowing the hash was reversible, so I apologize...

[distorto]

I almost didn't even mention storing the password in 2 places. I know it wouldn't add any security...I was just grasping at straws. Mentioning this problem on this forum seemed logical to me since the method used for password retrieval here at webmasterworld is exactly what I'm looking for. apparently

but it seem like you guys are saying there's no way to do this. what about reversing a hash - with a seed - yourself?

I'm very interested in doing the password retrieval this way if possible. I know that it's going to be more secure not to, but if there is a way to meet halfway or something...

[eelixduppy]

If you absolutely want to send them their password to their email do as PHP_Chimp suggested. Get yourself HTTPS and use the mcrypt to encrypt and decrypt the passwords. Store them encrypted in the database and only decrypt them when they retrieve their password. Take care to make sure that your php applications don't have any security holes that would lead to a breech in DB security, and make sure the emails are sent through secure connections.

[distorto]

thanks

[henry0]

I'll forget about email
When first registering ask for a bunch of questions
(Try to be creative!) Favorite teacher, favorite TV show etc..
If PW is lost:
First answer the questions; receive a hint
If that does not work
Then use the temp PW way

[whoisgregg]

hashing with a small additional string

Is absolutely necessary because, as you said "almost everyone uses md5."

Which means that if Site A uses md5($password) and Site B uses md5($password) then a hacker who knows the resulting hash need only find another string that results in that same hash.

So if my password is 'dog' and the hacker discovers the hash value stored in the database, then they need only find another string that will result in that hash. Since there is a virtually infinite variety of strings but only 16³² possible md5() results, there's gonna be overlap. However, if you use a seed, then the resulting hash doesn't reveal anything about the user-supplied portion of the original hash.

Every site should use their own unique variation of

md5( $user_password . 'a string unique to this site' );

Of course, if they know your seed you're screwed. But if they can see your source code you're screwed no matter what you are doing.

[lammert]

Of course, if they know your seed you're screwed. But if they can see your source code you're screwed no matter what you are doing.

That would imply that all open source software is in danger which is simply not true. Software sits as a layer between the visitor/hacker and the data, including the encrypted passwords and seeds. (at least if you didn't hard code the seeds in your software) Knowning the software may give information about possible holes in the software itself, but should not give much information about the data behind it.

[henry0]

But if they can see your source code you're screwed no matter what you are doing

For example if you have a structure like:
/var/www/html/ then it is your responsibility to hide in /www/ all your "sensitive details"

Further you may use zend guard (former zend encoder)
Not free to encode but free to decode for the end user that has the correct "clearance".

[borntobeweb]

When first registering ask for a bunch of questions
(Try to be creative!) Favorite teacher, favorite TV show etc..
If PW is lost:
First answer the questions; receive a hint
If that does not work
Then use the temp PW way

I don't get the point of these security questions. If i give a fake answer, it's just another password to remember. If i give the real answer, then i'm giving a third party yet another piece of private info and someone who knows me or takes the time to do the research can figure out the answer, and then the hint gives them an extra clue to crack my password. What am i missing?

[whoisgregg]

That would imply that all open source software is in danger which is simply not true.

Not want I intended to imply, nor do I think that is true.

Open source software which depends upon encryption requires the end user to provide a unique seed for each installation. phpMyAdmin for example requires the user to populate $cfg['blowfish_secret'] if you want to store encrypted usernames and passwords in cookies.

Seeing the source code of phpMyAdmin reveals nothing about the seeds in use for each installation, but seeing the source code of a particular installation would reveal the seed used in that installation.

So I should have been more clear in saying "if they can see the part of your code where you store secrets you're screwed."

[distorto]

"I don't get the point of these security questions. If i give a fake answer, it's just another password to remember."

the questions he's referring to are usually something like "what's your mother's maiden name?"
or "what's the name of your dog?"
The objective is to come up with questions you would not be likely to forget the answers to.