Who would have thought that by providing registration information on one site, you could make other online accounts vulnerable? That’s exactly what Dr Nethanel Gelernter and other researchers at the Israeli College of Management Academic Studies demonstrated via their paper The Password Reset MitM Attack presented at the 38th IEEE Symposium on Security and Privacy.
In their paper, the researchers show how Facebook, Google and others are vulnerable to the password reset man-in-the-middle (PRMitM) attack. Here’s how it works:
A user arrives at a website to download a white paper, get a discount or whatever: it doesn’t really matter, as it’s during registration that the user is compromised. Once they’ve provided their email address, the PRMitM scenario is initiated. As shown in the researcher’s diagram, the attacker immediately initiates a password reset for your email or online service account.
The security questions or one-time-passcodes challenges are passed directly through to the individual who is registering.
Spoofing the SMS
If SMS is used to validate your account, then the attacker’s registration site will also use SMS to validate you. When your service provider asks the attacker for the code sent to your mobile phone, the victim is asked on their registration form to input the SMS received. Once the victim provides the SMS on the attacker’s form, absent any additional protocols, the unsuspecting user’s email or other online service account has just been hijacked.
The researchers found that the less information accompanying the numeric code the more likely it was that the victim would use it without hesitation. However, SMS messages that identified the originator, provided an explanation – such as “password reset for your xyz-account” – and warned the user not to share the code with third parties were more likely to be challenged and not shared during the registration process.
Spoofing phone calls
Similarly, a password reset process that uses a phone call rather than an SMS is also vulnerable. The researchers found those that identified the originator, the purpose of the call and then interactively engaged the user, (with an instruction such as “Press 1 to receive your password reset code”) were more likely to be recognized by the user as being associated with the identified service and not appropriate for the registration process.
Security authentication questions
The researchers demonstrated, as have many others in the past, why we should avoid using or providing easily discoverable answers to security authentication questions (see the 2009 paper by Dr Ariel Rabkin, Personal knowledge questions for fallback authentication: Security questions in the age of Facebook). Sending a link – with as short a lifespan as possible – via SMS was the best option, noted the researchers.
If a website asks many questions that are directly related to the actions done by the user in that site, they cannot be forwarded to the users as legitimate security questions for other websites.
The researchers highlighted how Google asks questions germane to their engagement with users during their security question authentication engagement. Google’s own research in 2015 on the topic of personal knowledge questions demonstrated we are really terrible at those password recovery questions.
What are we, the individual user to do?
Let’s talk passwords. Very simply, and we say it every time the topic arises: One account – One Password. Use strong passwords and use them only once.
What about security authentication questions? The paper recommends that if given the choice to create your own security challenge questions, or use generic questions, you should make up your own and make them germane to the website, and unique to the website.
This means that if they pop up while you’re registering at another site, all your warning lights should be ignited.
And if you can’t set unique questions for each site, then use unique answers for each site. Your first pet: Spot, Rover, Charlie, etc. It doesn’t matter if those aren’t actually the right answer: what matters is that they’re the right answer for that one website.
We’d add that you should treat answers to security questions like passwords: make them long, randomly chosen and unique, and store them in a password manager.
What about sites that offer a password reset option?
The authors offer eight general guidelines, and then specific recommendations about using security questions, SMS code, and phone calls. Snapchat, Yahoo!, Google, Yandex and others are adopting the recommendations.
If you require your users to have a password, take the time to develop a multi-step process that requires the user to be engaged. It might be less convenient for the user, but the improvement in security makes it worthwhile: don’t allow convenience to trump your user’s security.
Of note, the researchers picked up on the NIST admonishment to not use SMS or phone calls as the sole means of authentication which is discussed in the NIST June 2017 Digital Identity Guidelines, and so should you.
And if you’re a website owner concerned about this kind of exploit, we’d also recommend that you get familiar with OWASP’s comprehensive guide to fending off cross-site request forgery attacks.
