In the past few months, we’ve seen a series of high-profile account breaches that gave control of users’ accounts to malicious thieves. I’m sure many will remember the Matt Honan hack, where an attacker was able to gain access to the journalist’s accounts and wipe his devices by fooling Apple support into resetting his password for them.

More recently, Skype proved to be vulnerable to the same attack, which is really bad news for password resets in general, because there’s really no good way for someone to guard against this. If you haven’t specified an email address (or if you forgot the password for your email address), how can a provider authenticate you? They will have to use security questions, or information about your account, or other ways of doing it.

Security questions are usually very low entropy, much lower than the actual password, and thus they should probably be discouraged. Unfortunately, many services (including banks) use them.

Alternatives

There are a few ways in which one can improve their verification process and help protect users against these sort of attacks. The product I’m currently working on, Instabot (it’s a hosted bot for team chat rooms, check it out, it’s very cool) uses the excellent Mozilla Persona for authentication, but I’m hoping they read this and pick up some of those methods.

Here are some procedures you can use to improve your password reset policies:

“Do not reset”

First and foremost, my favorite option, which nobody seems to implement, is simply to allow the user to ban password resets altogether. I have all my passwords in an encrypted database with a 70-character passphrase backed up instantly from all my computers, so any password reset option is (very probably) less safe than that.

I simply want support to deny all password reset requests, always. This is what we use at Silent Circle, and it’s the only option that completely stops this attack. Unfortunately, it might not be practical or feasible for all users.

Small credit card charges

If the user has a credit card on file with you, you could perform two small charges on their credit card (which you can refund later), and have the customer tell you the amounts of those charges. This has the advantage of moving the onus of trust on the bank, which (hopefully) has other good controls in place to prevent identity theft.

Some disadvantages of this technique are that the verification may not be instant, as, in extreme cases, the user might have to wait a month (or more) to get the bank statement in the mail). Also, if the user has not registered a credit card with you, this check will be impossible to do.

Issuing one-time reset codes

During (or after) the signup process, you can issue a long code to the user, which they can store and use in the event of a lost or forgotten password. This code could be stored somewhere safe, or printed. To make the latter easier, you might want to include a QR code of the URL in the page, so the user can print it directly and then scan it to easily reset their password.

The disadvantage of this method is that storing the code will be hard, it might get lost, and it can give full access to the account if not stored properly.

Phone resets

Similarly to the credit card method, if the user has a phone number on file with you, you can send them a short, time-sensitive, one-time reset token. They can enter that in the page and be allowed to reset their password.

The disadvantage is that it’s rare for a user to have a phone number registered on a site beforehand, and that this method is a bit hard to implement, as it requires sending SMS to any country in the world.

Ask personal questions

No, not that sort. Asking questions like “when did you last log in?”, or “what was your last transaction” are things an attacker probably will not know, but a user will. Unfortunately, unless the user is very engaged with your service, or your service has memorable interactions, this is unlikely to produce good results, simply because not many people remember the last time they logged into their accounts (or it’s so frequent that it’s not useful).

Conclusion

There are many ways to improve password resets, but asking for three people on the user’s contact list is not one of them. Your password reset procedures must be very easy for the user to answer, but very hard for the attacker.

Finally, do not forget the “Do not reset” option, which is a very simple and easy feature to implement, yet is very powerful for preventing attacks. The more sophisticated users are very likely to use it, and thus prevent the highjacking of their accounts.