Page 1 of 1
hashes
Posted: Mon Dec 26, 2005 7:17 pm
by blacksnday
My understanding is from a general website view,
hashes like md5, sha1, etc... can't be un-hashed?
So if I store a users password in sha1 then convert
the password post field to sha1 it can be matched,
but if needing to realize what the user's password is,
I can't un-hash it...
If that is the case, it makes me wonder about how
websites that offer the option
'Forget Password, input email to have it sent to you'
Are they storing the passwords in plain text somewhere on server?
Or are they somehow being able to convert any hased value?
Re: hashes
Posted: Mon Dec 26, 2005 7:43 pm
by foobar
You can be pretty sure that hashed values can't be "un-hashed". Although this is possibly, it's based on a dictionary of letters and phrases with their corresponding hash values [edit]They are huge and slow to the point where they are pretty useless for dictionary attacks[/edit]. For instance, you can decode some MD5 hashes on the following website:
http://gdataonline.com/
blacksnday wrote:
Are they storing the passwords in plain text somewhere on server?
Or are they somehow being able to convert any hased value?
Never! They use a form of encryption which can be decrypted with an appropriate key. How they generate that key is a whole different matter. This can be from the system time, your account name, or anything sufficiently random. A popular encryption algorithm are the AES and RSA algorithms.
Posted: Mon Dec 26, 2005 7:58 pm
by blacksnday
Thanks.
I am currently creating the start of my members system
and was wondering how to offer a forgotten password to
be sent to the user upon request.
Currently I have it set up so that no current password can be resent.
Instead you would have to submit certain info used when signed up
or by a link sent to the email you signed up with, with the link then
unsetting password when clicked allowing you to create a new one.
I would figure that not sending any current password through email
would be the best option, while instead making the user go through steps
in order to create a new password.
Posted: Mon Dec 26, 2005 8:04 pm
by josh
Here's my method
first i send an email with a link to reset the password
then the user is asked a "secret question" (sometimes i bypass this)
after the question is answered correctly i generate a 10-15 random alpha numeric string, email the password to them in plain text, store the hash over the old password, and instruct them to change their password as soon as possible, sometimes I'll set a boolean field in the database that forces them to change their password the next time they login.
I think this is a pretty standard way of forgotten password handling..
for added security I would also foce a user to confirm with their old email before changing their email, or even block an account from changing it's email for 24 hours after changing it's password
Posted: Mon Dec 26, 2005 9:13 pm
by Ambush Commander
Never! They use a form of encryption which can be decrypted with an appropriate key.
Well, that's what you "hope" they do....
Posted: Tue Dec 27, 2005 1:59 am
by AGISB
Ambush Commander wrote:Never! They use a form of encryption which can be decrypted with an appropriate key.
Well, that's what you "hope" they do....
Hehe my thought completely. I think most sites do it by just storing the password plain text in the database.
I have done it in the past as well as the company wanted it that way despite my objections. I however used a second table for the plain text passwords. This table was not accessable by the normal mysql php user and the only application able to access that table was the password retrieval tool.
This should be save enough because if anyone can crack into the mysql database the worry about a user password is mood.
Posted: Tue Dec 27, 2005 2:09 am
by blacksnday
AGISB wrote:Ambush Commander wrote:Never! They use a form of encryption which can be decrypted with an appropriate key.
Well, that's what you "hope" they do....
Hehe my thought completely. I think most sites do it by just storing the password plain text in the database.
I have done it in the past as well as the company wanted it that way despite my objections. I however used a second table for the plain text passwords. This table was not accessable by the normal mysql php user and the only application able to access that table was the password retrieval tool.
This should be save enough because if anyone can crack into the mysql database the worry about a user password is mood.
I would think that would be the easiest choice for them to do.
Not what I plan to do,
but it does make you wonder about accounts
you have on sites that offer that feature.....
Posted: Tue Dec 27, 2005 5:04 am
by onion2k
I don't store passwords as MD5 any more. Used to, but the whole forgotten password issue is too much of an issue for my clients. I now store passwords using MySQL 4.1's AES_ENCRYPT() function .. with a very long key. It's as hard to break as MD5 if you only have the database data in front of you, but has the handy feature of being reversible using AES_DECRYPT(). I figure that if it's good enough for storing credit card details then it's good enough for a user's password.
Posted: Tue Dec 27, 2005 5:19 pm
by d_d
AGISB wrote:This should be save enough because if anyone can crack into the mysql database the worry about a user password is mood.
Not really, plenty of users still put too much trust into the security of these systems. A fair few of them will use the same password on multiple sites. Getting a list of emails and corresponding passwords is useful if people reuse passwords on sites like ebay or paypal.
A list of emails and hashes is a lot less useful.
Posted: Tue Dec 27, 2005 6:04 pm
by Ambush Commander
Used to, but the whole forgotten password issue is too much of an issue for my clients.
I don't see how the forgotten password thing is a problem. There a lots of ways to resolve forgotten passwords even though you don't know what the password is as long as you have a valid email address.
Posted: Wed Dec 28, 2005 3:13 am
by onion2k
Ambush Commander wrote:I don't see how the forgotten password thing is a problem. There a lots of ways to resolve forgotten passwords even though you don't know what the password is as long as you have a valid email address.
Wrong. There is only one way to resolve a forgotten password if it's stored as a hash .. and that is to set it to a new password. I find users are happier if you can tell them what the password they've forgetten is. The problem of transmitting the password to the user exists whichever method you choose.
Posted: Tue Jan 03, 2006 6:51 am
by Maugrim_The_Reaper
The problem of transmitting the password to the user exists whichever method you choose.
Too true... Really, assuming the password is not stored plain text either method seems fine. Just so long as you keep in mind how the AES key is stored... But that's usually a separate security issue - bit like DB User and passwd. I agree that useability can often lead to encryption over one-way hashing. Hashing is generally more secure since its one-way and there's no local key for reversing it. I don't recommend one over the other - esp when you drag in useability and realise its one of those preferential balancing acts

.