Many of you may have seen How Apple and Amazon Security Flaws Led to My Epic Hacking, where a Wired reporter's Amazon, Apple, Gmail, and Twitter accounts were successfully hacked. The hacker followed an elaborate sequence of steps, at each step using the password recovery process at one web service to obtain information needed to attack the reporter's account on the next web service. The attacker was able to successfully exploit the variation among different services' requirements for what they require to perform a password reset, to chain his attack and eventually successfully mount a catastrophic attack on the poor Wired reporter.

In light of this, what practices should web services be following, to protect their password reset functionality and prevent recurrence of such a failure? What does the industry need to be doing to ensure this doesn't happen again?

  • For example: Should the last 4 digits of a credit card number be considered a reasonable authenticator (along with other information)? Apple was treating the last 4 digits as part of the information it required, to confirm a password reset. On the other hand, the last 4 digits of your credit card number may appear in a number of places (e.g., on a credit card receipt from a local store).
    – D.W.
    Commented Aug 8, 2012 at 7:05
  • 3
    It's not just the variation of requirements that permitted the attack, but the fact that those requirements are so low. Neither Amazon nor Apple required anything but semi-public data (credit card number, pet name, etc. hamper automated attacks but are not difficult to obtain with a bit of target-specific work by a human). Commented Aug 8, 2012 at 9:16
  • Poor Journalist, he lost all his family photos and memories, and he can't recover it with legal action. Recoverable data is mission-critical, he should guess why it was so easy for hacker - because he did not secure it himself but relied on very weak process. Commented Aug 8, 2012 at 13:16
  • When going through the a Password Reset process, should web services present an error if a user enters an email address that does not exist in the system? The argument for seems to be that otherwise the user expects an email but never gets it, but the argument against is that is reveals whether or not an email is valid within the service and may be worth attempting to compromise. Commented Jan 7, 2017 at 22:19

4 Answers 4


I've actually been working on some ideas around this area, so here's a dump of my thoughts so far. I apologise in advance for the ridiculous length of this answer.

Password reset mechanisms have to be designed with three major goals in mind:

  • Security
  • Usability
  • Reliability

For a good mechanism, we need to reach a balance between the three.

A few assertions that I'd like to make before starting:

Right, on to the actual answer!

1. Multi-factor authentication

Multi-factor authentication (MFA) is one of the most secure methods for account recovery, and human authentication in general. For those of you that are unfamiliar with MFA, it works on the principle that you must have more than one credential in order to authenticate:

  • Something you know (e.g. password, secret answer)
  • Something you have (e.g. key, hardware token, etc)
  • Something you are (e.g. fingerprint)

Note that having multiple of one type, e.g. two passwords, or a password and a pin, does not count as MFA. I'm looking at you, online banking sites.

1.1. Something you know

When resetting a password, a common way to authenticate the user is to ask them some questions. Unfortunately, these questions are usually things like "What school did you go to?" and "What's your mother's maiden name?", which are incredibly easy for attackers to find out through social networking. Furthermore, many users dislike answering these questions when signing up, so they just hit a bunch of keys and invalidate the purpose of the question.

For e-commerce webapps, and other webapps that store private personal information (e.g. address / phone number), one might ask for that information. However, keep in mind that this information might be found online too.

An alternative would be to ask contextual questions, based on the user's experience on the site. For example, Hotmail asks for an email address that you have recently communicated with, as well as some other information about activity on your account. This is quite adaptable across most types of webapp, but isn't always applicable.

1.2. Something you have

Often sites will describe emailing a link or one-time password to your email address as a form of MFA. I assert that this is a false assumption. Users share passwords between accounts. This is an absolute fact, and you cannot prevent it. As such, you must assume that an attacker already has access to the user's email address. We'll cover the implications of this later.

The proliferation of cellphones has made them a great mechanism for two-factor authentication, as a form of out-of-band check. SMS reset tokens are easy for the user to understand and use, and an attacker having access to the phone is unlikely. However, this method is not without flaws. The biggest problem is when a user loses their phone, or changes provider. This completely invalidates the phone as a usable reset device. Another problem is that users don't always have their phone with them.

Using an app on smartphones partially fixes this problem. If a user changes their provider, the app remains on the phone. Allowing both SMS-based and app-based resets allows for a reasonable expectation of reliability.

Alternatively, allow the user to associate a login provider account (e.g. OpenID) and use a valid logon for that account as a "something you know" proof.

Other potential mechanisms:

  • Physical token (e.g. RSA SecurID, USB token) - not exactly viable for most places, but useful for banks, internal corporate systems and other high-security situations.
  • File - Randomly generated file given to the user on signup. Hash stored in database. Upon reset, user asked to provide file. Not the best usability or security, but potentially useful.

1.3. Something you are

This is where things get fun and sci-fi. Biometric authentication is something that has become more popular recently. Quite a few laptops include fingerprint scanners, and you can pick up cheap USB ones for a relatively small cost. Another popular biometric mechanism is facial recognition, via webcam. Both of these are excellent in terms of security when done right, but they both have a few problems:

  • Most implementations are probabilistic, and therefore insecure. What stops an attacker from holding a photo of your face up to the camera?
  • You can't rely on every user having a fingerprint scanner, and those that do aren't all compatible with each other. Furthermore, you're interfacing with hardware, so that requires a native app to talk to your webapp.
  • The field of biometrics is relatively new, so there aren't any well-aged properly-studied implementations with fully understood security models.

All in all, the "something you are" model works for in-person identification, but isn't really feasible for webapps unless you're providing your customers with fingerprint scanners and appropriate software.

1.4. MFA best practices

Single-factor authentication is not enough. As we've seen from all the recent breaches it's difficult to keep passwords secure, and even when they're hashed they can still be broken. MFA is necessary for both login and password recovery. Mobile authentication for recovery purposes solves most problems, as long as the mobile device is still usable. In the case of mobile authentication not being possible, you must have a manual verification process in place, where they have to convince a human that they are the real deal.

2. Reset mechanisms

There are a multitude of different password reset methods out there, many of which fall way behind in terms of security. I'm going to discuss some that I've seen in the wild, explain their good and bad points, and propose some better ones.

2.1. Emailing the password back

The most basic mechanism is to just email the user's password to them. Please don't ever do this. It's horrible beyond measure. First, it requires that you're storing passwords in cleartext, or at least in a reversible format. You must hash passwords properly, and follow best practices for salting. Second, you're emailing the user's password in cleartext, over a cleartext protocol, over the internet. There's a special level of hell reserved for people who do this.

2.2. Generating a new password

Some sites generate a new random password, hash it, then email it off to the user. This isn't a good idea for quite a few reasons, though most of them can be mitigated in some way. The most fundamental issue is that you're emailing a usable password to a user in plaintext. Other issues with this method include:

  • Many users are lazy, quite a few will reset and just tell the browser to remember the random password.
  • A lot of sites don't force you to change the password upon first use of the password.
  • An attacker having access to the email account has access to the password, regardless of what mechanisms you used to authenticate the user in the first place.

2.3. The reset link

This is one of the better (and, thankfully, more popular) mechanisms. It involves authenticating the user, then emailing them a one-time reset link. Once the reset link is used, the user is prompted to set a new password. Once that's been done, the link is invalid. Further security can be provided by including expiry times on the links, and enforcing that the link is invalid after the password is set or after the user's session times out.

The downfall of this method is when we remember our earlier assumption. The user's email account is not safe. It does not count as "something you know". Whilst an attacker's time window is short, they can still break in. Of course, all of this is further invalidated if (or, rather, when) the user forgets their email password.

2.4. Never leave the site

This is the holy grail, really, but can only be used alongside strong multi-factor authentication. Once the user authenticates themselves using a combination of security questions, out-of-band checks (e.g. cellphone), key files, biometrics, human verification, etc. they are immediately redirected to a password change form. This entirely bypasses the need to use email addresses at all.

If you truly believe that using an email address to send a link to is necessary, consider offering a no-email reset option which increases the number of checks that you require to be passed.

3. Conclusion

It's difficult to balance security, usability and reliability at the best of times, but this situation is directly dealing with a user that has already proven themselves to be unreliable. I'm not saying this in any kind of deprecating sense, but rather that we are all fallible.

It's important to keep a password reset system usable and simple, without skimping on security. Before implementing a massive 3-factor authentication process on every aspect of your webapp, think about what you're protecting. If you're just a small company selling things online, you can probably get away with basic 2-factor on recovery. If you're a major retailer, bank, or social networking site, you should be using strong 2-factor on recovery (multiple types of each), and 2-factor on logins from unrecognised sources.

In a sentence: keep it simple, think about your audience.

  • 2
    This is a thoughtful analysis, yet it leaves me feeling unfulfilled. You argue that 2FA is absolutely necessary, and you explain how not to do password recovery, but you don't explain what to do when a user has lost their password and so is down to one factor at best (and often no factor, e.g. because they've had their phone stolen, which was in fact their sole factor since the password was only stored in the phone's browser history). Commented Aug 8, 2012 at 16:35
  • @Gilles I mention it briefly at the end of section 1.4. If a user completely loses everything, they must convince a human that they own the account, by answering questions about recent usage, private info, etc. It's the only solid way to enforce security in the case of entirely lost credentials.
    – Polynomial
    Commented Aug 9, 2012 at 7:46
  • 1
    Well, that's what Apple and Amazon did here. Only their notion of convincing a human was providing name, address and credit card number. I think how hard the human should be to convince is the key problem here. Commented Aug 9, 2012 at 8:31
  • @Gilles I'll have a think on it and write up a few guidelines on human verification. The problem is that the available information for validation is highly dependant on the site itself. For example, there's almost zero private activity on a StackExchange site, so it would be difficult to come up with a strong human validation scheme.
    – Polynomial
    Commented Aug 9, 2012 at 8:35
  • Based on this answer, I'm going to propose a password reset solution where a confirmation code + link is sent as sms. Commented Oct 10, 2014 at 14:21

The problem with the "epic hacking" was that multiple accounts (twitter, gmail) were linked to one account (icloud) which then got compromised, allowing the hackers to request and intercept password reset links for the linked accounts.

If you want to protect against such a scenario (where an email account used as reference for other accounts is compromised) imho there is no other way than using 2factor authentication, as offered by Google. If the temporary password obtained through social engineering would have been sent to the mobile phone of the owner of the icloud-account, none of this would have happened.

  • I just now set up the 2-factor authentication settings offered by google at the link you provided. It is an excellent system, with an easy set up process: SMS to your phone for a one-time code for authorizing an unknown computer to access your Google credentials, etc. Commented Aug 8, 2012 at 17:27
  • 1
    But be ready for the more cumbersome steps at the end, wherein you generate a separate password of 16 random lowercase characters for each non-browser app that will access your Gmail account, e.g, Outlook. So the more apps you have accessing your Google account, the less likely you'd be to ever change your Google password. Commented Aug 8, 2012 at 17:46

In my opinion, there is nothing more a web service can do to protect the password reset functionality for one simple reason, the user.

Let's consider what i find to be the most common form of password resets: the secret question. There are 2 scenarios which usually plays out.

1) Answer the question truthfully - many users choose this route. Unfortunately, answers to most secret questions are incredibly easy to dig up from the internet. Information such as your first school or your mother's maiden name is hardly a secret. Attackers can easily dig up such information by performing simple online searches. This makes the secret question as good as useless.

2) Answer the question with rubbish, then forget about the answer - most people i know do this, including me. This effectively renders the secret question useless as it cannot be used to confirm the legitimacy of the password reset request.

The best way to handle the secret question would be to answer with rubbish, but write it down somewhere so you don't forget. Most users will not do this however, mainly due to the fact that they don't care about security until something happens.

What are some other common ways to trigger a password reset?

Email - many services link your account to a "recovery" email. However, what happens if you forget the password to the recovery email? It is a never ending chain.

Many of the more secure methods like two factor authentication are a hassle for the users. Web services have to consider usability vs security. After all, what is the point of having an unhackable web service if no one uses it?

The main flaw in that article is that the author had multiple accounts linked to one email, which allowed the attacker to compromise all his online accounts easily. Try, as much as possible, to decentralize your online identities. However, this becomes the users responsibility.

As much as we would like to think that security should be the main concern of web services, we have to consider the usability point of view. Security overall will not improve until the end users realize how important it is and take steps to protect themselves. After all, there is only so much a service provider can do.


In practice, they used his email to hack everything. So keeping your email secure, best on your own, with smart intrusion detection, and protected from password recovery, would prevent such hack in this case.

Same goes for your data in the cloud. Smart encryption and system protection, like key management are important for you to keep secure plus the remote backups and snapshots, so simply it's not possible to daisy chain.

These two - key documents and communication, has to be secure, hence it's not suitable for cloud for a professional use, because somebody will delete it and that's it. So the best is to use a business / personal domain, which you can recover legally.

Having it protected legally, physically, with smart automation, you can use it for business use, and if you got hacked, it should basically be aware of the password recovery via email, basically in your webmail you should filter password recovery to another mailbox you need to access via ssh, to be safe.

What about apple? This happens when you use hardware for kids with apple remote control. It is good solution to ipod, but it doesnt work in the real PC world. How everybody was annoyed when microsoft was collecting data, but now apple has all applications under control and it's OK to some degree, but mainly for the home fun and entertainment, not a professional work. Security leap of OSX is huge, and it's not surprising at all that the OSX was hacked cross-platform way.

For a secure email, the best is also to have domain in reputable company, so it cannot be hacked too.

  • 2
    There was nothing the user could have done to prevent his e-mail from being hacked in this case - the attackers side-stepped any possible user-implemented security by going straight to the service provider for access. So, "they used his email to hack everything. ... So keeping your e-mail secure... would prevent such attacks." is not effective advice for this scenario. Also, having your e-mail "...domain in a reputable company..." did little to keep it from being broken into here. This is just proof can be "hacked" (in this case, mostly social engineered), it's just a matter of when and how.
    – Iszi
    Commented Aug 31, 2012 at 15:15
  • 1
    In short, the question here asks for solutions that should be implemented on the service provider's end. Your recommendations here do not at all address that, and in fact mostly address topics which would have been of no help at all in this case.
    – Iszi
    Commented Aug 31, 2012 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .