MD5/Salted Password Recovery In ASP

Soldato
Joined
8 Oct 2005
Posts
4,184
Location
Midlands, UK
Hi,

The following has just coem to mind and I can't think how I can go about it.

During signup, a user eneters a password of choice, before inserting into the database (SQL Server) the password joined to a random salt string and then MD5'd. This is fine for when the user logs in, as I can MD5 the users input and work from there.

However, my issue comes when I'm tryingt o implement a last password form/page. Usually, you'd enter something like an email addy and the password would mailed to that address. I can;'t think how I'm going to email this password back.

Does anyone have an idea how I can go about this?

Thanks
 
I think for sending the plain text password back you need to have 2 way encryption.

Just generate the user a new password, MD5 it with salt, put it in the database and email that to the user's email address. Also, since you aren't emailing the user's plain text password here you've prolly increased security - for instance, someone leaves their mail client open, someone else knows a site they use, requests the password, now they have a plain text password and can break into more sites that person uses (if the password is the same).

Once the user has been emailed a new password then they can just change it to whatever they want using a change password page.
 
I think for sending the plain text password back you need to have 2 way encryption.

Just generate the user a new password, MD5 it with salt, put it in the database and email that to the user's email address. Also, since you aren't emailing the user's plain text password here you've prolly increased security - for instance, someone leaves their mail client open, someone else knows a site they use, requests the password, now they have a plain text password and can break into more sites that person uses (if the password is the same).

Once the user has been emailed a new password then they can just change it to whatever they want using a change password page.

Surely I'd have to send the newly generated password back to the user in text format?
 
Surely I'd have to send the newly generated password back to the user in text format?

Yes but the newly generated one will be a random password generated by you (i.e. it won't be connected to any other site the person uses - since many people use the same password for multiple websites) so will be useless apart from accessing the one site.
 
I can't remember anything recently that sends the plaintext password back to the e-mail they provided - surely this is pointless if you can get the password back from the hash?

Paypal, netload (I think anyway) send you a new password which you have to maybe change in login, or generate a link where you can create a new password after answering some security questions - why don't you do something like this ?

Edit: what was previously said :o
 
Best thing to do would be to email them a link to a password reset page with a short-lived one time token (10-15 minute window) that would allow them to set a new password.

You could also have a link in the email saying "click here if you didn't request a password reset" so that you can immediately invalidate the token and save any logs of who requested it to follow up with (automated abuse report springs to mind).
 
Yes but the newly generated one will be a random password generated by you (i.e. it won't be connected to any other site the person uses - since many people use the same password for multiple websites) so will be useless apart from accessing the one site.

Yer, good point, didn't think of that :)

I can't remember anything recently that sends the plaintext password back to the e-mail they provided - surely this is pointless if you can get the password back from the hash?

Paypal, netload (I think anyway) send you a new password which you have to maybe change in login, or generate a link where you can create a new password after answering some security questions - why don't you do something like this ?

Edit: what was previously said :o

As its only for a small internal system that may be a bit much - I basically just need a cheap and cheerful way for a forgetful user to get access to the system when I'm not there.
 
As its only for a small internal system that may be a bit much - I basically just need a cheap and cheerful way for a forgetful user to get access to the system when I'm not there.

If that's the case, just generate a random password for them and email it - much simpler and they'll probably change it upon first login anyway.

This allows you to keep the passwords hashed (much more secure than simply encrypted IMHO as people often use the same password across many different sites).
 
If that's the case, just generate a random password for them and email it - much simpler and they'll probably change it upon first login anyway.

This allows you to keep the passwords hashed (much more secure than simply encrypted IMHO as people often use the same password across many different sites).

Yer thats the route I'll use I think, for the little extra effort it takes I always hashed/salt passwords before saving to a database (well, ever since I read robmillers article).
 
Hi,

The following has just coem to mind and I can't think how I can go about it.

During signup, a user eneters a password of choice, before inserting into the database (SQL Server) the password joined to a random salt string and then MD5'd. This is fine for when the user logs in, as I can MD5 the users input and work from there.

However, my issue comes when I'm tryingt o implement a last password form/page. Usually, you'd enter something like an email addy and the password would mailed to that address. I can;'t think how I'm going to email this password back.

Does anyone have an idea how I can go about this?

Thanks

I added a 'Forgotten password' to my registration system fairly recently and did it like this:

User requests a new password, a random ID and their username is then entered into a separate table. The ID should be pretty long so it can't be guessed, obviously (maybe generate a nice SHA1 string or something) :)

The user is then sent an email containing an address to reset their password e.g. resetpass.php?i=random_id

This page contains the usual password and repeat password boxes, this is where the user can enter their new password.

Once they press submit the username is retrieved from the table with the random ID, the reset password random ID is then removed from the database and the user's password and salt fields are updated.

I'm not sure if this is the most effective way, but from what I can tell it's pretty secure and it works :)

I plan to put some kind of time expiry on the random IDs in the reset password table. I've not got round to that yet though.
 
Last edited:
I added a 'Forgotten password' to my registration system fairly recently and did it like this:

User requests a new password, a random ID and their username is then entered into a separate table. The ID should be pretty long so it can't be guessed, obviously (maybe generate a nice SHA1 string or something) :)

The user is then sent an email containing an address to reset their password e.g. resetpass.php?i=random_id

This page contains the usual password and repeat password boxes, this is where the user can enter their new password.

Once they press submit the username is retrieved from the table with the random ID, the reset password random ID is then removed from the database and the user's password and salt fields are updated.

I'm not sure if this is the most effective way, but from what I can tell it's pretty secure and it works :)

I plan to put some kind of time expiry on the random IDs in the reset password table. I've not got round to that yet though.

Sounds like a good idea.

For your time issue, maybe you could add a further field, and insert a date/time when the random id expires (E.g. x mins from now).
 
Sounds like a good idea.

For your time issue, maybe you could add a further field, and insert a date/time when the random id expires (E.g. x mins from now).

Yeah, sounds like a good idea :)

Although I'm not sure yet how I'm going to make it delete from the database after a certain amount of time.
 
Back
Top Bottom