Fog Creek Software
Discussion Board




"Forgot Password" Website design

Long time listener, first time caller here.  I have been reading the posts on this discussion forum for quite some time.  I work for a small shop doing usability testing, program testing, installation development, etc, etc.  Judging by the programming skill and knowledge in this forum I will most likely never have the programming ability as the majority of the people reading this post.  Nevertheless, I’ve got a question.  I am currently testing a password retrieval web application designed in C#.  Here’s how it works,

Users are given a username and password to log on to our website.  Within a “Portfolio” page the user provides all sorts of required information, most importantly their email.  Let’s say once the user provides us with their information they forget their password?  Here is how they get into the system:

First, they click on a “Forget Password” link on our website.  Second, they are brought to a page where they must submit their username and email address.  If the username and email address do not match within our database an error is returned to the user.  Third, they are sent an email with a link that will return them to our website where they must provide the last four digits of their Social Security Number.  Fourth, once they correctly submit the last four digits of their SS# they are brought to a new page where they must change their password.  We never give them their old password we make them set a new one.

This is proving to be very difficult for our users to understand.  It would be a lot easier if we could have the user click on a Forget Password link, validate their username, email address, and SS# and send them their existing password via email.  What does everyone think?  Any help on this would be greatly appreciated.

In the Midnight Hour She Cried More..More..More..
Thursday, April 08, 2004

> It would be a lot easier if we could have the user click on a Forget Password link, validate their username, email address, and SS# and send them their existing password via email.

It would be even easier if they only have to submit their email address, and then you send the password by email: this assumes that no-one but me can receive my email.

Christopher Wells
Thursday, April 08, 2004

If you have their SSN I'm assuming you have a certain amount of trust with this client. It's your responsibility to not give something like their password in something as sniffable as their SSN.

Have them enter the last 4 digits of their SSN and let them set a new password after that.

www.MarkTAW.com
Thursday, April 08, 2004

In the app we're building now, I've decided to go with the lost password form really being a reset password and send it to the email address on file form.  For two reasons:
(1) We encrypt our passwords one way in the DB, so we cannot retrieve them and show them to the user.
(2) It will greatly simplify the process.  Just click on the link, and enter the email address, along with some kind of additional verification.  If it matches one that is on file (when a new account is created, we force the email address to be unique), the password is reset to a randomly generated string and emailed to that address.

We have to use some kind of verification to prevent a random person from annoyingly resetting people's passwords if they can guess their email address.  But it is only one form, and two fields.  The verification could be zip code, last name, etc. or possibly some kind of cutesy challenge question like "What is your dog's name?"

Beyond that, I don't see the need for more.

Clay Whipkey
Thursday, April 08, 2004

Ask only for the email address; the username is redundant. 

Include the username in the email -- people forget those too!

If you don't want to include the password in the email -- put a link in the message that includes an encoded component (using something like MD5).  This encoded component is linked to the user's username and password.

When the click is clicked, the user is brought to a page where they can change their password.  As a side effect, when the user changes their password the link will no longer work.

Almost Anonymous
Thursday, April 08, 2004

> password in something as sniffable as their SSN.

should be "as sniffable as email."

www.MarkTAW.com
Thursday, April 08, 2004

> Ask only for the email address; the username is redundant. 

Good idea. Say, what's your email address? No reason... now what was that site you signed up with?

Sorry, you can't base your security on all publicly available information.

www.MarkTAW.com
Thursday, April 08, 2004

"Good idea. Say, what's your email address? No reason... now what was that site you signed up with?"

Well I think the idea is that the rest of the process is still followed (i.e. you get an email at that address that you have to follow, and then d othe following steps).

Personally I entirely agree : Most "usernames" on websites are entirely redundant, not to mention suffering from classic namespace collisions ("damn...dennis_Forbes is taken...dennis_w_forbes...dwforbes, d_w_forbes, etc): I already hae a globally unique email address. The only sites that should require usernames are sites that display 'handles" on messages, although even that can be just an account attribute rather than a logon element.

Dennis Forbes
Thursday, April 08, 2004

"Good idea. Say, what's your email address? No reason... now what was that site you signed up with?"

Just how would you get my username and password if I have you my email address and a site I've signed up with?!?

Almost Anonymous
Thursday, April 08, 2004

Thanks everybody for the insight!  I was just looking for a easier way to do this, but of course security has got to make things a bit harder.  Our biggest problem is probably that our users are not very Internet savvy.  Or even Windows 95 savvy. 

"Almost Anonymous"  if our users forget their username they can call our helpdesk.  Surprisingly, this is rarely the case because most of these usernames (ID's) were issued roughly 1-30 years ago.  We incorporated these usernames into the web application.  I guess you could say they are a lot like SS#'s.  As for two users "not" having the same email address , we recently got burned on that.  We have several users (husband and wife) that have the same email address.  That's why we now have to ask for the username.  On top of all that we are using an encoded component.  Thanks for the replying so quick! 

In the Midnight Hour She Cried More..More..More..
Thursday, April 08, 2004

also, after a sucessful password change,  you may want to send the email address a notice that the password has been changed, just in case it wasn't them that changed it.

apw
Thursday, April 08, 2004

Just ask for _either_ their username (I'm assuming it's unique) or their e-mail address (which you know from the "portfolio page"); use that to lookup their record and send the username and a new, randomly generated password to the e-mail address on file.  If they'd like, they can change it from a page on the site (a link to which should also be included in the e-mail).

bpd
Thursday, April 08, 2004

"use that to lookup their record and send the username and a new, randomly generated password to the e-mail address on file."

This isn't good -- if someone mistakenly types in someone elses username or email address they'll clobber that persons password!  Sure, they'll get the randomly generated password in their email but I still think it's a bad idea.

Almost Anonymous
Thursday, April 08, 2004

The problem is that IMHO a well-designed application shouldn't be *able* to retrieve the user's password - it only stores a hash, hashes the input password, and compares the hashes. In that situation, you don't have the option - you generate a new password (use the old AOL method of dictionary word & random symbol & dictionary word) and email that out.

Philo

Philo
Thursday, April 08, 2004

Almost,
That is why in our approach (which I explained in an earlier post) we ask for the email address AND some piece of verification.  That could be the last 4 digits of the SSN#, a special challenge question, whatever will make you feel like you've got your bases covered.

Then when you send your script in to do the resetting of the password, you only do it if you find a match for the email address AND the verification item.

IMHO, this is the method that addresses as much user-friendliness as you can get while still maintaining good security.  (Being able to *see* what someone's password is at all is a problem waiting to happen.  Forcing them to reset is the only option if you encrypt one-way.)

Clay Whipkey
Thursday, April 08, 2004

Philo++

Also, you may want to also use a "salt" value when computing the hash.

joev
Thursday, April 08, 2004

The method I used in a similar situation was to ask for either the email or username, from that, I look up the user record, and if exists, send a token (good for that day) to the email address.

Then I ask the user to enter that token (along with their username or email, but if they leave the browser open it's pre-filled anyway), and then send a new password to the email address on file.

The one thing that is... poor in my system is that a password reset doesn't invalidate the code used to authenticate the reset, but I think I'll look into that next week. :)

Ryan Anderson
Thursday, April 08, 2004

Always start from a threat model. What is it you are trying to protect, and what is it you are trying to protect against. Once you figure this out, you can then evaluate different options. There is no "general" always best solution to this problem.

Just me (Sir to you)
Friday, April 09, 2004

As a user, here is what I like (an dislike) about various user/pass systems:

I like systems that let me use arbitrarily long usernames -- I have a standard username for web-based accounts that I like to use. Systems that only allow a certain number of characters annoy me, as I often forget my username -- and then don't revisit the site much.

I like systems that use my email address as my username, *** but only if they can absolutely guarantee that they won't spam me or sell my details ***.

I like systems that don't place restrictions on my password. I know that using dictionary words, names and birthdates is bad, and so I don't do it. But having a password policy that makes it really hard to remember the password means I'll forget it.

I like what my bank does: they ask for a username, my account number, my date of birth and then 3 digits from a security code that I can chose (i.e. they specify "third", "second", "last"). This is probably overkill for a web-app, but I like the challenge-response idea of e.g. "third", "second", "last" digits, as it means that at a given sign-on, not all of my authentication details are transmitted across the network (and encryption is also used).

An alternative to passwords would be to ask users to choose a pass-phrase (e.g. "the cat sat on the mat"), and then, when they sign on, ask then for the, say, "first" and "fifth" words. It's easy to remember, as secure as passwords (still vulnerable to stupidity and social engineering), but is not easily sniffable over the network.

I like sites that, when I sign-up, ask me for a challenge question (I might choose the question "Where was your first visit overseas?") and a response ("Germany"), so that if I forget my user/pass, they ask me my question.

tinfoil hat
Friday, April 09, 2004

Most sites send you the user name and password when you put in the previously entered email address.

This does mean you should make sure you have a strong password for your email address. There was an article in the "Arab News" last week from a Saudi lady journalist who found that somebody had broken into her Hotmail account and changed her password and then texted her on her mobile to demand she withdrew the unveiled photo of herself that appeared with her articles, and aplogized for allegedly "Unislamic" behaviour. If she didn't do this the Hotmail hijacker threatened to post her emails all over the web!

There are some amusing side-lines to this. Firstly the poor woman appeared to be genuinley miffed that Hotmail and Bill Gates wouldn't do anything to help her get her account back but expected all that to change after she had published her article. Secondly that the hijacker was idiot enough to contact the woman by SMS, thus identifying himself, at least indirectly to any criminal investigation, and thirdly that the woman, despite having denounced the matter to the Interior Ministry hadn't realized that this was the way to catch the guy.

It also raises questions about the common sense of people who have weak passwords, and worse still, keep the only copy of their address book within the Hotmail account.

Incidentally, having your email account hijacked is quite common when you fall out with your girlfriend/boyfriend, so be forewarned.

Stephen Jones
Friday, April 09, 2004

*  Recent Topics

*  Fog Creek Home