hashes

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
blacksnday
Forum Contributor
Posts: 252
Joined: Sat Jul 30, 2005 6:11 am
Location: bfe Ohio :(

hashes

Post 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?
foobar
Forum Regular
Posts: 613
Joined: Wed Sep 28, 2005 10:08 am

Re: hashes

Post 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.
User avatar
blacksnday
Forum Contributor
Posts: 252
Joined: Sat Jul 30, 2005 6:11 am
Location: bfe Ohio :(

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post 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
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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....
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post 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.
User avatar
blacksnday
Forum Contributor
Posts: 252
Joined: Sat Jul 30, 2005 6:11 am
Location: bfe Ohio :(

Post 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.....
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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.
d_d
Forum Commoner
Posts: 33
Joined: Wed Jul 07, 2004 4:56 pm
Location: UK

Post 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.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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 ;).
Post Reply