PayPal and their MFA implementation

Written on 22 September 2019, 12:49pm

Tagged with: ,

So, I’ve been locked out of my PayPal account because I was using Multi-Factor Authentication (MFA) with Google Authenticator codes.
After I changed my phone I noticed that (1) on the new phone, Google Authenticator was empty and (2) there was no way to log in to PayPal without the Google Authenticator codes:

No other way around this…

The PayPal call center is unable to help me for the moment.
There are multiple take-aways from this, and probably the most important is to use an authenticator app that backs up the accounts in the cloud. Google Authenticator doesn’t do this. Authy does.

2 days later: re-gained access to my PayPal account ?
I called again PayPal and this time I got in touch with a very competent agent, who understood the problem immediately, and after confirming a few personal details over the phone, disabled the MFA remotely so I could log back in.

Over the weekend I spent some time analyzing how other services are implementing MFA. Here’s an overview:

SMS / voice
codes
Authenticator
codes
Security keys
(Yubikey)
One time
backup
code
1. GMail
2. Twitter
3. Dropbox
4. LastPass
5. Yahoo✅ (also
email)
6. Cloudflare
7. Report-URI
8. IFTTT
9. Booking ✅ (also
email)
10. PayPal

Here’s a short analysis of the table:
– some services are really permissive: they give you plenty of MFA options to choose from and if, for some reason you are unable to use one of them, they happily offer alternatives. Google, Dropbox and LastPass fall into this category
– a second category of services give less MFA options, but immediately offer fallback options in case things go wrong: Yahoo and Booking.com offer to send you a one-time code via email (secondary email in case of Yahoo) in case you are unable to receive the SMS code
– a third category of services are more restrictive: they only offer authenticator codes as MFA, but they still provide the one-time backup codes when you set up MFA. Cloudflare, Report-URI and IFTTT do this
– finally, there’s PayPal. At first sight, they also fall into one of the ‘permissive’ categories: they give you two MFA options. The fundamental difference from the rest of the pack is the fact that PayPal allows you to set up MFA with only one MFA option – in my case, Google Authenticator codes. Even if PayPal had my phone number on file, it did not use it to send fallback one-time codes because I did not explicitly set it up as a MFA option.

Conclusions

First of all, I am ready to admit that it was primarily my fault. Back in April 2019, when PayPal finally offered auth codes for MFA, I was one of the firsts to enable MFA. But I didn’t bother to set up also the phone as secondary MFA option, for a number of reasons: first, as trained by the other services above, I assumed they will use my phone to rescue me if needed. Second, we all know that SMS codes are not as secure as the auth codes, so why bother? Third, the PayPal UI never made clear the risks that I am running by only using a single MFA option.
I also failed to use an authenticator app that backs up the codes. Again, my bad.

That being said, there are certainly other PayPal users who enabled MFA with only one option. When they will lose access to that MFA option, they will be at the mercy of the PayPal support agents.

I also think that PayPal could have done things a little better themselves.

First, their user support process is not perfect. I would expect that all the call center agents to follow the same procedures and to know exactly how to troubleshoot a customer issue. But expectation was not met in my case. During the first call (Saturday morning), the agent offered to change the password, then told me to call the mobile phone operator (!). Finally, she promised to call me back, but I’m still waiting for that call.
The second agent I called fixed my problem in literally 2 minutes.

Second, I think PayPal could and should offer more MFA options:
– One-time codes that you can save in your password manager work well and are offered by other services like Cloudflare, Report-URI or IFTTT
– security keys work just as well and are widely used (Google, LastPass, Dropbox, Twitter, etc)
– if you still decide to use only one MFA option, they should warn you about the risks

Third, they have an automated process to change your PayPal password. You answer the security questions, confirm your credit card number and mobile phone and you’re ready to go. Why not use the same automated process to reset/disable the MFA? In the end this is what happened over the phone – so why introduce the human factor into the picture?

Finally, there is the discussion about the pre-generated one-time codes and rescue codes received by email. They are not technically MFA since they are not something that you have, but something that you know. I got it, and in principle, I agree with it. But in my opinion, implementing the perfect MFA would only be possible in a perfect world. Major players handling people’s sensitive data (like Google, LastPass, Booking.com) make some compromises for better usability. PayPal doesn’t do them, but it doesn’t mean that they don’t do other security mistakes:

  1. for years they only offered SMS as MFA. They only introduced authenticator codes in April 2019
  2. their procedure to change the password over the phone is really permissive. Anyone who could get access to a person phone can reset their PayPal password. On top of that, the interface to change the password over the phone is the one from 10 years ago, not allowing copy/pasting passwords
  3. if they want to be really strict, then not simply delete/close my account after being locked-out? I will never have a valid Authenticator code, so technically, I should never be able to log in to my PayPal again. But they were able to manually disable my MFA over the phone in 2 minutes after confirming my name and my phone number.

So, MFA implementation is not easy. The services offering MFA might do some steps towards usability, but it’s primarily the user responsibility to make sure they do MFA right.

Comments (1)

Leave a response