Having enumerated my thoughts on multi-factor authentication best practices, I’d like to talk about one of the many ways not to implement 2FA.
If you have a web application available on a custom domain, your domain name registrar is a significant and appealing target for would-be attackers. Imagine if someone took control of your registrar account and thus had the ability to do anything they wanted with all of your domains. How much damage could they inflict?
With that in mind, some folks have been clamoring for domain name registrars to implement multi-factor authentication (MFA). In one notable example, customers requested that Namecheap replace its insecure SMS-based MFA with a more-secure TOTP-based solution… back in 2013. Nearly four years and several broken promises later, Namecheap’s CEO pledged to deliver MFA with better security by July 10, 2017, the very day I was scheduled to present a talk on multi-factor authentication at EuroPython. I presented my talk, and the day came and went.
The next day, on July 11, Namecheap announced their new 2FA solution. Yay! And it’s a TOTP-based solution. Double-yay!
“Wait, what the… Why do I have to set up SMS text message 2FA first? And then I have to install their branded mobile app? What on earth for?! I already have a general-purpose TOTP app that works just fine!”
A few weeks later I met up with Pieter Levels, one of the people who had put pressure on Namecheap to provide a more secure MFA implementation, and I shared my frustrations with him. He echoed his comments from his follow-up post on the topic, saying he would have preferred standard TOTP also but wanted to at least acknowledge that Namecheap had made a step in the right direction. I see his point.
At the same time, I can’t help but wish Namecheap better understood the reasons why their solution is sub-optimal:
- requires a phone (standard TOTP does not)
- requires users to share their phone numbers
- requires custom app installation
- does not work with standard TOTP apps
- uses SMS as account recovery method
While these are all significant drawbacks, the last one is the most critical — and the most embarrassing. The SMS text message-based 2FA set-up step is required because SMS is used as the recovery method.
This is bad. Really bad. Namecheap has completely nullified the TOTP-based security by allowing it to be bypassed with insecure SMS-based account recovery. In effect, they replaced their insecure SMS-based MFA that everyone was complaining about with — you guessed it — a method that can be bypassed via the same insecure SMS-based security hole.
Even if that weren’t the case, among the many problems listed above, I want to highlight Namecheap’s decision to require a custom app because this is an irritatingly common practice. At least one of my financial institutions also does this, and it’s completely unnecessary. What if everyone who implemented MFA did the same thing? Can you imagine installing and managing dozens of needless apps on your phone, just so you can log into the web sites you use on a daily basis?
Unsurprisingly, the comments on Namecheap’s announcement post were, shall we say, less than receptive. People are livid. As they deserve to be.
Don’t force your users into installing your custom app in order to secure their accounts. Allow users to use standard authentication apps that interoperate with your standards-based MFA implementation. Anything else is a disservice to your customers, and ultimately, your business.