Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Bridging the Security Gap: Two-Factor Password Recovery

DZone's Guide to

Bridging the Security Gap: Two-Factor Password Recovery

In this article, we look at how companies can employ the two-factor model of authentication to help users recover lost or forgotten passwords more securely.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Authentication by password is totally eighties – or so they say. Still, this type of authentication is used ubiquitously and it will almost certainly persist as the canonical method of access control in the near future.

In this blog, we investigate the possibility of improving the security of password reset procedures for web sites. And we will consider doing this in a low tech and low budget way only. We explicitly do not take into account either expensive set-ups or hardware intensive techniques, nor do we consider farming out authentication to an external authentication provider. This is not meant as a principal statement about the suitability of those techniques or services. There are certainly lots of use cases for them. Sometimes though, our requirements may demand a simple and low-cost solution. So, here we go …

There has been a lot said about security issues related to passwords: regarding their required length, complexity, the switching of passwords after a certain period of time, the pointlessness of doing so, etc. But whatever your password policy, one thing will not change – users will forget their passwords.

Ok, if I forget my online banking password or even enter the wrong one more than twice I have to go through a routine of calling the bank and have them unlock the account and/or send new credentials by snail mail. And that's probably ok, as the potential of abuse and damage is rather high – and because for reasons of accountability, a bank always wants to be on the safe side. But what if you don't have the resources of a bank, no 24/7 call center availability and manpower to send real paper letters to customers? What if the service you offer is not just so high risk?

Methods to Handle Lost Passwords

There seem to be several traditional ways to handle lost passwords at a sub-bank level which we are going to investigate. One word of caution though – all of them rely on one precondition: The user has sole access to a non-compromised email address that is stored with the user’s data. We will not question this precondition here – otherwise, it's back to the security level of a financial institution and sending the user new credentials by mail.

Here are the low-tech password recovery methods I’m aware of:

    1. You have the user answer one of those infamous questions (What is your mother's maiden name?) and then do … just what exactly? We'll come back to this question in a moment.

    2. You email the forgotten password which you have stored in plain text in your database to the user.

    3. Because you did not store the password in plain text but as a (hopefully salted) hash, you cannot send it by email, but you can generate a new one and send this.

    4. You send a link with a limited lifetime to the user's email address. This link enables the user to reset the password.

Now let's have a closer look at each of those methods.

Number 1 replaces an authentication method that is not very safe with something that is really unsafe. If you use this, you should seriously think about completely revamping your password recovery procedure. Anyway, in case the user answers the question correctly, what is the next step? Let her enter the new password immediately? This seems rather audacious. I guess it's on to numbers 2 to 4 to make the account accessible again.

If you use number 2 (plain text stored passwords), you have a serious security issue. You need to switch to storing hashed passwords as soon as possible. And sending a “real” password over the net in an unencrypted email compromises the user’s (and your site’s) security even more than just storing it. Besides, whatever the experts may recommend, the user is likely to use the same password with other sites, which makes sending it over an open channel even more dangerous.

Generating a new password as in number 3 and sending it by email is certainly one level above alternative 2 but it has certain drawbacks. Some of them can be addressed, some can not. First, if you replace the existing password with the new one, the old one cannot be used anymore. If somebody other than the user clicks the "forgot password" link we get a kind of DNS attack on the user's account. This can be countered by a two step procedure: first, send an email to the user with a request for confirmation and then send the new password in another email. Or, alternatively, you temporarily allow two passwords – the old one and the generated one. Which will not exactly make your software less complicated or more secure.

Second, you will send a valid, albeit temporary, password in an unencrypted email. This means that quite a lot of people will have access to the new password. Is the user is going to swap the new password for one of her own creation soon? For all you know, she may come back a year later. And do you enforce the replacement of the generated password at all?

Right. On to number 4. This is somewhat better. Here you have gained two advantages over number 3: There is no period during which the old password has been rendered unusable by a generated new one and the link is not valid forever but only for a limited amount of time. Well, at least I hope that's the way you have implemented it.

But still – while the link is valid, anyone in the world (with the power to read other people's emails) can abuse it.

By the way, the generated passwords of alternative 3 could also have a limited lifetime. However, I have the feeling that the concept of a link of limited validity is easier to convey than a password with limited validity.

Two-Factor Password Recovery

What we need is a low budget and low tech way to safely let the user restore access to her account. We have usually one, insecure, channel to convey recovery information to the user: email. So, two-factor password recovery to the rescue. Well, I guess the ideal two-factor set-up requires two factors from different domains, i.e. two out of the three "something you know" (e.g. a password), "something you own" (a cell phone, a hardware token, …), "something you are" (biometrics).

Something you own and something you are involve expensive and fickle set-ups. Let’s try to make do with a kind of poor man's two-factor recovery instead, using two types of something you know. And that's how it works:

Two Factor Password Recovery

Use alternative 4 and send the user a link of limited validity. Additionally, show the user something she has to remember when coming back to create the new password. This can be a number, a word, a picture, a color, whatever. So, when she requests to have her access restored, let her enter the email address and display one item of the second factor randomly chosen out of the set of all items. As the simplest example, you generate a random number. You display this number on the page where the user requests the password recovery and ask her to remember this number. You send the link to the email address and when she clicks the link, you have her enter the generated number. If it is correct, she can proceed to create a new password. If it is not correct, you do whatever you deem reasonable depending on the criticality of the account. This can range from invalidating the link after a few failed attempts and let the user request a new recovery link, including a new random number, to locking the account completely and request a phone call by the user. Whatever …

Memorability Issues

Numbers are hard to memorize for most of us (it’s always allowed to jot it down, though …), so instead, you could use a word from a dictionary. Here we obviously have a trade-off between security and usability. Using numbers, especially long numbers or maybe even dictionary entries from a large dictionary renders the chance that an attacker simply guesses right more or less negligible, especially if we block the procedure after a few failed attempts. On the other hand, the more complex the item to remember is, the more usability suffers. So, the opposite end of the scale would be something like displaying a picture or a color and let the user chose the correct item out of a set of pictures or colors on return. This set would by necessity be quite limited in size, otherwise, usability would be severely reduced. Note that this would drastically increase the probability for an attacker to just guess correctly.

I can imagine other types of second factors:

    • Let the user enter some (any) text of her own when requesting the new password and re-enter it on return. This has the advantage of better memorability by the user and the disadvantage of better predictability by an attacker.
    • Display a map and let the user pick a location on the map. Let her pick the same location on her return to the page. You would have to allow for a certain degree of fuzziness here. Here, too, memorability and predictability are increased.
    • Let her draw a doodle … hum a song? Involves intricate software and is probably going to have a high error rate.

Ok, we are drifting off into the department of weird ideas, let’s keep it simple and stick to numbers or words.

Final Words …

So, what are the pros and cons of two-factor password recovery?

Pros:

    • It is low budget. No extra hardware or complicated set-up is needed.
    • It is very easy to implement in software.
    • It is easy to understand for the user (or so I hope). There is a trade-off between higher usability and higher security by using easier to remember items out of a smaller set or harder to remember items out of a larger set. I don’t see easy to remember items out of a large set yet but there may be a solution to this.

Cons:

    • Passwords are still involved.
    • The higher the security of the second factor, the harder it gets for the user to remember it (obviously this is a pro and a con).
    • If you use dictionary words (which to me seems to be the best compromise between security and usability), you might be forced to restrict them to a subset like nouns, adjectives and/or verbs. I assume that presenting the user with function words like “like” or “or” might be counterintuitive and thus reduce usability (“’or’? Huh?”). You’d have to weed out the set of nouns, adjectives, and verbs, too, so as not to hurt some people’s feelings. While the first task can be automated, the second would probably have to be done manually (at least if there is no off-the-shelf set of nice words).

And finally… somehow it seems unlikely that no one came up with this idea before, but I didn’t ever encounter it in the wild, nor could I find a description of it anywhere so far. So I thought it worth while to present it here. If you have seen it or something like it somewhere, I’d be glad for a hint.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
authentication ,security ,password management ,usability

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}