Password recovery or reset solution for CF application
(I'm very grateful for all replies. Maybe some expert can answer other than the noble gdemaria, who I am prob gonna drive to drink with my incessant questions.)
Platform: CFMX 7, MS Access 2003
I've been looking in CFMX Bible and the Forta CFMX 7 book for a model or example that I can emulate, but have not found anything. Here's the problem. I need a way for a user to recover her password should she lose it.
I have a table, Users, that has these columns:
UserID
Username
UserEmailAddress
Password (this is a hashed value)
Salt (this is a salted value)
Firstname
Lastname
Users are able to register their information, and select a password. That password is salted and hashed, then stored in the database.
What if user forgets her password?
Plan A:
She could go to the login.cfm page and click on a link, "Lost your password?", which should take her to a password recovery page. That recovery page would have a simple form and a Submit button. She would enter her email, and her password would get emailed to her.
I imagine I can do that using the handy CFMAIL tag. But how do I retrieve that salted and hashed password from my table Users, above, and contain it within an email sent to the email address the user specified?
That might not be possible. My understanding of salt and hash is, you're not supposed to be able to unsalt and unhash it. At least not without a big computer and a lot of time. Correct?
I don't think there's a CF function to unsalt and unhash a password.
* Interesting Wiki article on Salt cryptography: http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Plan B:
So, I am thinking of a Plan B. A user should be able to reset her password. She would need to be able to do so without logging in, of course. So she needs to be able to enter her email address in the Password Recovery (or, Password Reset) form, and then, several things happen:
1. a new password is generated randomly, salted and hashed, and stored in the database, replacing the old values
2. this new password, in plain text, is emailed to her
Plan C:
She contacts the site admin and asks for a new password.
Plan D: Some other plan I have not thought of.
What is your view of this situation? I need some means to assist a user who has lost her (salted, hashed) password.
Suggestions?
Gratefully,
Eric
Platform: CFMX 7, MS Access 2003
I've been looking in CFMX Bible and the Forta CFMX 7 book for a model or example that I can emulate, but have not found anything. Here's the problem. I need a way for a user to recover her password should she lose it.
I have a table, Users, that has these columns:
UserID
Username
UserEmailAddress
Password (this is a hashed value)
Salt (this is a salted value)
Firstname
Lastname
Users are able to register their information, and select a password. That password is salted and hashed, then stored in the database.
What if user forgets her password?
Plan A:
She could go to the login.cfm page and click on a link, "Lost your password?", which should take her to a password recovery page. That recovery page would have a simple form and a Submit button. She would enter her email, and her password would get emailed to her.
I imagine I can do that using the handy CFMAIL tag. But how do I retrieve that salted and hashed password from my table Users, above, and contain it within an email sent to the email address the user specified?
That might not be possible. My understanding of salt and hash is, you're not supposed to be able to unsalt and unhash it. At least not without a big computer and a lot of time. Correct?
I don't think there's a CF function to unsalt and unhash a password.
* Interesting Wiki article on Salt cryptography: http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Plan B:
So, I am thinking of a Plan B. A user should be able to reset her password. She would need to be able to do so without logging in, of course. So she needs to be able to enter her email address in the Password Recovery (or, Password Reset) form, and then, several things happen:
1. a new password is generated randomly, salted and hashed, and stored in the database, replacing the old values
2. this new password, in plain text, is emailed to her
Plan C:
She contacts the site admin and asks for a new password.
Plan D: Some other plan I have not thought of.
What is your view of this situation? I need some means to assist a user who has lost her (salted, hashed) password.
Suggestions?
Gratefully,
Eric
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yes, I prefer the salt + hash method too because IMO its a little more secure.
Good Luck!
Good Luck!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Gentlemen,
These are very useful suggestions.
I am working firstly to remove the salt + hash encryption, and to use the CF Encrypt function. The LiveDoc that _agx_ pointed out has pretty good instructions to do that.
>>>I would enjoy always entering my co-worker's email address so he gets locked out
Spoken like a true villain. I like it.
I am going to close this question for now, b/c I have a good plan with which to continue. I need to focus on other parts of this application, to keep the client happy. I might come back to this topic asking for further advice.
For now -- thank you.
Eric
These are very useful suggestions.
I am working firstly to remove the salt + hash encryption, and to use the CF Encrypt function. The LiveDoc that _agx_ pointed out has pretty good instructions to do that.
>>>I would enjoy always entering my co-worker's email address so he gets locked out
Spoken like a true villain. I like it.
I am going to close this question for now, b/c I have a good plan with which to continue. I need to focus on other parts of this application, to keep the client happy. I might come back to this topic asking for further advice.
For now -- thank you.
Eric
> I am working firstly to remove the salt + hash encryption, and to use the CF Encrypt function
Encrypt / Decrypt is good for credit card numbers where its absolutely necessary to be able to get the card number back so you can charge the card again (like for monthly subscriptions)
However, if you want a truly secure password scheme, stick with the one-way hash. This is used by banks and other financial institutes where the staff will NEVER know a client's password. They can't because of this hash. Its more secure than encrypt. You just have to do things like reset instead of giving them the password. Depending on how secure you want to be, you can unencrytpt and send the password or be more secure and send a new password.
ASKER
OK. So, keep salt + hash, but the strategy is to reset, not retrieve, the password.
I'm gonna work on this, as soon as I figure out the bulletin board thing, and a couple of other things. =)
I'm gonna work on this, as soon as I figure out the bulletin board thing, and a couple of other things. =)
>> I would enjoy always entering my co-worker's email address so he gets locked out
We won't even ask where you work .. or more importantly ... how your co-worker's retailiate ;-)
We won't even ask where you work .. or more importantly ... how your co-worker's retailiate ;-)
I know this is closed, but I just had to add ..
>>If the user recalls their original password, the are allowed access and
>>the tempPassword is cleared
If you're not designing a secure (ie banking application) I'm sure this is fine. But truthfully I'm a little less enamoured of that method. Resetting a password generally means the old password is invalidated as a security measure. It strikes me as being less secure if you temporarily allow access via 2 different passwords - even if its only once. If you prefer not to use an email address alone, another option is to add a security question. Though that has its down sides as well.
But as I said I'm sure having 2 viable passwords at one point in time would be acceptible for most basic applications.
>>If the user recalls their original password, the are allowed access and
>>the tempPassword is cleared
If you're not designing a secure (ie banking application) I'm sure this is fine. But truthfully I'm a little less enamoured of that method. Resetting a password generally means the old password is invalidated as a security measure. It strikes me as being less secure if you temporarily allow access via 2 different passwords - even if its only once. If you prefer not to use an email address alone, another option is to add a security question. Though that has its down sides as well.
But as I said I'm sure having 2 viable passwords at one point in time would be acceptible for most basic applications.
ASKER
_agx_,
That's a good idea. I was thinking about a security question too. (But what if she forget the answer to her security question?)
This isn't a banking application, but the content of the site will be sensitive in a medical, clinical way. The site deals with participants in a study of Uxoricide. The clinicians need to maintain confidentiality, and they need to demonstrate to funders that their clinical information is secure.
On the other hand it's not like a Swiss bank or anything.
So, I'm still debating this. Your and gdemaria's comments are very useful. I'm not sure how I am going to handle this. I'll probably just build something and see what I get. That's my usual method. =)
Have a great evening.
Eric
That's a good idea. I was thinking about a security question too. (But what if she forget the answer to her security question?)
This isn't a banking application, but the content of the site will be sensitive in a medical, clinical way. The site deals with participants in a study of Uxoricide. The clinicians need to maintain confidentiality, and they need to demonstrate to funders that their clinical information is secure.
On the other hand it's not like a Swiss bank or anything.
So, I'm still debating this. Your and gdemaria's comments are very useful. I'm not sure how I am going to handle this. I'll probably just build something and see what I get. That's my usual method. =)
Have a great evening.
Eric
> But as I said I'm sure having 2 viable passwords at one point in time would be acceptible for most basic applications
agx's point is valid, although I am very sure that sometimes when I ask for a new password from a site, and then I suddenly remember the password, I can still get in and I ignore the email they send me. Not sure how they are doing it but I am certain others have done this (that does not mean its good, just that it exists).
I think a secret question is a valid approach, it's like a second password. Although I think its important to have a long list of questions to choose from, too often the list contains things that people may know like your Pet's name or the make of your car. The user should remember it because its something they know, the trick is to keep the answer to a single word. Examples: the name of your first pet, the street name where you grew up, your favorite cousin's name, your favorite TV show growing up, etc..
Of course the secret question doesn't change how you store the password or what you do if they can't get their secret question right. Also, if they do get their secret question, what do you do? Show them the password? You cannot if you have it hashed, so the secret question is only a verification that you can reset their password and email it to them. But you have to watch out for email addresses that change, I get locked out all the time because I used an old email address that I can no longer access. So, after the secret question, just have them change their password right then without emailing or telling them anything.
agx's point is valid, although I am very sure that sometimes when I ask for a new password from a site, and then I suddenly remember the password, I can still get in and I ignore the email they send me. Not sure how they are doing it but I am certain others have done this (that does not mean its good, just that it exists).
I think a secret question is a valid approach, it's like a second password. Although I think its important to have a long list of questions to choose from, too often the list contains things that people may know like your Pet's name or the make of your car. The user should remember it because its something they know, the trick is to keep the answer to a single word. Examples: the name of your first pet, the street name where you grew up, your favorite cousin's name, your favorite TV show growing up, etc..
Of course the secret question doesn't change how you store the password or what you do if they can't get their secret question right. Also, if they do get their secret question, what do you do? Show them the password? You cannot if you have it hashed, so the secret question is only a verification that you can reset their password and email it to them. But you have to watch out for email addresses that change, I get locked out all the time because I used an old email address that I can no longer access. So, after the secret question, just have them change their password right then without emailing or telling them anything.
>>> a secret question is a valid approach, it's like a second password
No, in this context its more like a captcha test, but one used to differentiate between the real owner and mischievious co-workers. Obviously, if you require a security question, you will need an administrator as a backup in case all methods fail. But you generally need an application adminstrator anyway. Especially for sites with critical or sensitive information.
I think the dual passwords is a good approach for systems with low or no security concerns, like a help forum, where automation is a high priority. Ultimately, I think it comes down to which is more important. If automation is the highest priority, then you should probably consider the dual password method. If security is more important, than the minor inconvenience of a security question /administrator may be preferrable.
No, in this context its more like a captcha test, but one used to differentiate between the real owner and mischievious co-workers. Obviously, if you require a security question, you will need an administrator as a backup in case all methods fail. But you generally need an application adminstrator anyway. Especially for sites with critical or sensitive information.
I think the dual passwords is a good approach for systems with low or no security concerns, like a help forum, where automation is a high priority. Ultimately, I think it comes down to which is more important. If automation is the highest priority, then you should probably consider the dual password method. If security is more important, than the minor inconvenience of a security question /administrator may be preferrable.
ASKER
I really appreciate these comments. They're very informative. I'm still talking with the client about the password retrieval situation. She might just say: "If they lose their password, they should contact you." (I'll be ongoing site admin.)
I'm leaning toward automation / convenience over high security. We'll see what happens. I still need to build it.
Have a great evening.
Eric
I'm leaning toward automation / convenience over high security. We'll see what happens. I still need to build it.
Have a great evening.
Eric
I'm lazy in that regard, so believe it or not I agree with you guys about automation, but its always good to think "what if this application were storing MY information" ? If you suddenly feel a burning interest in security ... then maybe your application isn't as secure as it should be :)
Night
Night
> If they lose their password, they should contact you
Users won't like that. Even my bank, which now has site-keys, has the ability for me to resolve a forgotten password. I strongly recommend something, whatever you decide; email, reset, secret question...
Users won't like that. Even my bank, which now has site-keys, has the ability for me to resolve a forgotten password. I strongly recommend something, whatever you decide; email, reset, secret question...
ASKER
I think you're right. I'll do something.
It might also be a good idea to ask the client if there are any specific security requirements mandated by funding / contracts. Determine what flexibility you have up front.
ASKER
I'll work on this and see how far I get. More later...
Eric