Software

Five password reset options for online apps

Programmer Justin James presents five common ways to reset passwords for online applications and explains which two of the options provide the most security.

I recently had a discussion with someone about what goes into a good self-service password reset system for online applications. It seems like such a trivial thing, but it brought up a number of important security issues, which related to how we write our applications. I am going to lay out some common password reset approaches, what kinds of scenarios they work best in, and when to use one over the other.

Option 1: Email the original password

A good number of applications email the original password out. This is absolutely horrifying. It means the programmer has the password available either in plain text or a two-way encoding that can easily be turned into plain text. Forget for a moment the security implications of sending a password via unencrypted email; what happens when an attacker gets a hold of that database, or manages to get it to start coughing up that data? Everyone who uses that password on other popular sites is at risk. Not only should you never do this, your system should not be capable of doing it.

Option 2: Email a new, random password

This is not the worst choice in the world, especially for a site that doesn't have much sensitive data. You can just send out a new, randomly generated password, and suggest (or force the user) to change it when they log in again. The security is provided by their email system. This is a potential security hole itself, but for a low-value system without the kind of data hackers would be interested in, this can work just fine.

Option 3: Email a limited time password reset link

Another path that uses email as the identity validation system is to send out a link that contains a long string of random characters that leads to a one-use, limited time password reset screen. This is more secure than option #2 because the link can only be used once and with a limited window that it can be exploited if the link got into the wrong hands. It still has the weakness of using the user's email system as the determinant of identity, though.

Option 4: Secret questions

More and more sites seem to be moving to the secret question scheme, where when the user signs up, they are asked questions that only they should be able to answer, like their mother's maiden name or their high school mascot. In my opinion, this is an incredibly insecure system.

First and foremost, anyone who knows me well (or is friends with me on Facebook) already knows or can find out my mother's maiden name, what high school I attended (and therefore, its mascot), my birthday, the first car I ever owned, my favorite pet, and more. To make matters worse, secret questions are often stored in clear text, which means that if a hacker gets the database for one site, they can answer secret questions at many sites. And unlike passwords, it is very unlikely that I am going to use different answers to the same questions on different sites.

The only time secret questions are truly secure is when they rely upon a site-specific piece of information, perhaps something that was provided non-electronically (like an account number that only appears in paper mail from the company).

Option 5: Reset via phone

Some sites are now sending a confirmation code through SMS messages to perform password resets. I like this strategy a lot. "Hacking" my SMS address involves actually getting a hold of my phone (or planting a virus on it, and some phone operating systems, like Windows Phone 7, won't allow apps to read SMS anyways), which is an entirely different level of security breech.

The big downside is for users without access to SMS messaging; depending on your target audience (such as military personnel in highly secured locations, people in remote areas, etc.) this may well be the case. It also presumes that you have a way of sending SMS messages, which is not the easiest task in the world and usually involves signing up for a third party, paid service.

Which option to choose?

In my opinion, options #3 and #5 provide the most security. Option #3 does not send any passwords through the email, and if the email system is hacked, compromised, or otherwise exposed, the attacker has only a limited time to do something with it. For example, if your emails end up as court evidence, no one can take action on the one-use, limited-time link (thanks to Chad Perrin for reminding me of this). Option #5 has the advantage of requiring physical possession of the authentication device. In addition, it avoids email completely. Out of the other three, option #4 is probably the worst, because it requires you to store sensitive data that is not relevant to the application, data that is dangerous in the hands of an attacker, and the authentication is based upon easily obtained information.

J.Ja

About

Justin James is the Lead Architect for Conigent.

10 comments
TobiF
TobiF

In Sweden, my mothers maiden name is publicly available information. You just need to call the civic registry and ask... So: In most cases, when I'm forced to enter answers to some s.c. secure qestions, I'll just throw in a bunch of total gibberish. I don't even bother to remember it. Hmm. A bank wanted me to answer some secure questions. But I had to pick one of their questions, and most of them were irrelevant. "Favorite colour?" How would I know? I depends on my current mood... right? Favorite team? People who know me, know I may enjoy watching a good game, but never bothers about teams and tables. I left that bank...

Realvdude
Realvdude

Another issue with this would be a matter of user trust in a website. I would share my mobile number with my bank if required for security, but I don't think I would share it with Yahoo, Google, Amazon, eBay/PayPal, etc... because I don't trust them not to spam me with SMS ads or calls.

sysop-dr
sysop-dr

I was wondering and I have yet to try, but say that we added a level of security to the email a time limited hash link to a user by requiring that the user have a private public key pair. They would register their email and the public key with the site. Then when you send them a reset hash link you first encrypt it with the public key and then they could decrypt it with the private portion that only they have. While the encryption is breakable the time limit effectively eliminates that and you can send the hash link in public email. Now most people do not have a private/public key but there is no reason that they couldn't. We have used things like pgp for email before, why not apply it to this reset password application?

apotheon
apotheon

The biggest problem with the "secret question" option is that it does not actually do anything for security at all. As you point out, Justin, using information about you as your answer means your answer can be researched by a malicious security cracker (or suspicious spouse, for instance), and storing the answers in plain text can create some problems. It gets worse than that, though. Consider that to overcome the first problem, you would have to enter an "answer" that has nothing to do with the question, and is difficult to guess or brute-force. Consider as well that to overcome the second problem, a service provider just needs to hash the answer the same as one should do with a password. What do these two solutions tell you? They tell me that the "secret question" technique is nothing but a password by a different name. If you use a "secret question" for password reset, then, one of two things happens: either the user chooses a password that is weaker than the main password so that it's easy to remember for recovering or resetting a lost password, or it's just a second password that is used less often and thus more likely to be forgotten. It is, at best, completely pointless. At worst, it provides an easier way to compromise security.

tony.law
tony.law

Option 6 is to avoid online passwords altogether. A lot of UK banks are using variants of this - don't know how far this is spreading in the US? For one account, I have a device that recognises my account PIN code (only ever sent out by secured snailmail, to the registered address) and provides a ten digit one-time logon key. For another, the device requires my Visa card to be inserted, needs my PIN, and has separate functions to deliver a logon key or a transaction validation key; the latter also requires information about the transaction. A third bank still uses a two part password system, but has a phone interface to validate transactions - a code is displayed on the screen, and must be entered into the phone system (landline or mobile, selected per transaction, but the phone numbers are pre-registered with the bank). These last two conform to the "something you have, something you know" criterion for security. BTW: in the UK at least, text messages can be received on some landlines either as text (if the phone supports it) or as text-to-speech voicemail. BT does this, I don't know about other providers. So, Option 5 isn't necessarily out of court if you're out of coverage.

Justin James
Justin James

... is that it is a layer of complexity which few users understand. Look at the lack of penetration of keys for email, for example. It's a good idea, and for internal applications it may be realistic, though. J.Ja

Realvdude
Realvdude

Though I know several questions do not compound the hacking a hude amount. For many years I have been using unrelated answers.

apotheon
apotheon

Why not offer it as an option for those who aren't stunned by simple cryptography tools?

apotheon
apotheon

It's the best security for password recovery or reset likely to be offered. I wouldn't call that bloat. > having it in the UI A small link doesn't add much clutter to the UI -- and that link could lead to a page where encrypted emails can be requested. Beyond that, it's the responsible thing to do, not only for purposes of offering your users the best security they might want to use, but also for purposes of giving people more reason to use encryption. . . . and I know several people who are equipped to send and receive OpenPGP encrypted files, but don't use it to digitally sign their emails. They tend to sign only when specifically requested or otherwise needed.

Justin James
Justin James

I'll put it this way... I've been using email for roughly 15 years now. You and Chip are the only people who have ever sent me a signed email more than once or twice, and I deal with plenty of tech savvy people. If two people out of thousands are using signed email, I'd have to say that adding this feature to a site would be "bloat" based on usage. While it's not too hard to do it, and it's a good idea, having it in the UI and the codebase would be more trouble than its worth to the users. J.Ja