That Time Enabling Two-Factor Authentication Made Me Feel Worse
I’ve been an account holder at a fairly prominent online brokerage for a while now. Been using it without a hiccup for years. If you are new to the stock market and trading, you may want to look up trading platform fees such as eToro Gebühren to be aware of what you’ll be getting into. The movement in the stock market early in the year prompted me to log in to check on a few things (I know, I know. I swear I’m not that guy). While there, I decided that it was time to set up two-factor authentication (2FA) on that account (again, I know, I know. But there’s a legit reason I hadn’t so far, trust me). One of their supported choices as a second factor is an app-based soft token (something like Google Authenticator or Symantec VIP), which is what I decided to go with. I went through the registration process, which was pretty easy and the kind of registration process I’ve been through more than a few times before. So many times, in fact, that I didn’t bother to see if I had set up correctly (I’ve never encountered a scenario where it hasn’t) by logging out and logging back in.
2FA Done Badly
Fast forward a month of so, and I receive the customary email about tax documents being available. Diligent guy that I am, I go to log in so I can download them before I forget. Unfortunately, I forgot that I set up 2FA during my last visit.
The user ID or password you entered does not match our records. Please try again.
No biggie, I think, probably fat fingered it, so I try again, making sure CAPS LOCK isn’t on.
The user ID or password you entered does not match our records. Please try again.
Hmmm. Maybe if I type it in slowly and carefully, paying special attention to make sure I capitalize the correct letters.
The user ID or password you entered does not match our records. Please try again..
(At this point, if you’ve been following my blog at all, you’re wondering about something. So let me reassure you that I do indeed practice what I preach and use a password manager for all my online accounts – except for my financial accounts.)
Genius that I am, my next move is not to remember that I set up 2FA, but to instead think of their app on my phone, which I have Touch ID enabled. Opening it, the authentication screen brings up the Touch ID prompt. I press my thumb to the sensor, and…
The user ID or password you entered does not match our records. Please try again..
At this point, I’m pretty concerned. I start wracking my brain, pondering all the possibilities. Has my account been hacked? That’s when my eyes stray back to my browser window, and I suddenly note that in the error message, past the usual messages about ‘recovering your username’ and ‘resetting your password’, is a “learn more” link about protecting my account using a Security ID. A “Security ID”? Oh yeah, I enabled 2FA on my account, I suddenly remember.
But that doesn’t explain why my password isn’t working. Or does it? On a hunch, I click on the link and read more. That’s when I find out that what I should be entering in the password field is not my password, but rather the concatenation of my password and the code from my soft token app.
Seriously? I recognize that because I think of myself as an “expert” user – not only because of my work but also because I have set up and used 2FA on so many other accounts – I skipped the instructions as I went through the registration process and probably missed reading this particularly important detail. But I haven’t seen a more glaring reminder of how creating a bad user experience in security can completely screw the user up. I and others have spoken in the past about the importance of paying attention to Usability in Security, and how bad usability can actually introduce vulnerabilities into a system. The folks who implemented this probably patted themselves on the back about being able to add 2FA to the existing authentication process without changing the screens or flows. But in doing so they introduced several usability fails:
- They completely ignored years of training and understanding that end-users have developed regarding security flows. People see a password field with the label “password”, they type in their password. While this trained behavior can be a bad thing (it’s what phishing relies on), it is also not to be ignored when implementing a solution to a common use case. Break the users expectation and you end up undermining their confidence in your system.
- They not only messed with what is now a fairly standardized user experience. they made it measurably worse. First off, they made it completely unintuitive. Secondly, anyone using a soft token app has encountered the scenario where the token expires right before you finishing typing it in. In this model, that requires me to re-enter the whole password again as part of the concatenated “password”. That is why every service I’ve encountered asks for the second factor in a separate step. Well, almost every, I guess.
- Their 2FA setup process could have made this change to the login flow a lot clearer and more explicit for the user, instead of expecting the user to go through a “learn more” link to figure this out.
- Their error message was not contextually helpful at all. Expecting a user to debug a bad interaction is just…bad.
Anyway, having figured out what I was supposed to be doing, I tried again and…
…no luck. This time I got a message that I was locked out. Apparently the last login failure on my phone locked the account for too many failed authentication attempts. The message told me to call customer service to set a new password.
Missteps in Account Recovery
I decided to wait a few days before calling. I wanted to see if the lock would just expire, as it probably should. It didn’t. I also never received any email notifications informing me that my account had suffered multiple failed login attempts. So I finally called them up a few days later. Here’s how it basically went:
- Called them from my home phone (which is the same number listed on my account profile). I honestly don’t know if this got used at all
- The automated system asked for either my SSN or my Account Number
- Got connected with a representative
- Representative asked me for my name
- When I said that my account was locked, he asked for my date of birth and the username on the account
That’s it. That was all that was required for my identity to be verified. Was surprised as none of the details I provided would have been hard for a determined hacker to obtain (and I’m pretty careful). And it really is nothing if they are not actually verifying the number I called from against what is listed on the account.
Now, what I expected at this point was that they would simply unlock the account, which would allow me to use my existing password (along with the security code, of course). However, this was where I got my next surprise. They did not have an account unlock capability, only a reset forgotten password capability. The process involved them setting a temporary password on my account, which I could combine with my 2FA security code and use to log in and immediately set my new password. When I asked if they could simply unlock the account, he said that they could not.
I haven’t had a need to go through this process before I set up 2FA, so I don’t know if the account recovery process is any different when there is 2FA on the account. The fact that the temporary password had to be combined with the expiring security code from my second factor does alleviate some of the concern. But if the process is the same without 2FA, then the barrier to taking over an account is not very high at all. There have been a number of incidents that have highlighted just how easy it is to obtain the kind of personal information used in their process from other services, which can then allow you to take over accounts. It is sad that my analysis of the Mat Honan hack still holds. The mechanisms for identity verification used in account recovery processes are still woefully inadequate, and continue to be the achilles heel of our online security.
Anyway, back to my adventure. After verifying my identity, the representative gave me a 6 (!) character temporary password. Once I combined that with my security code and logged in, I was directed to set a new password, which I did (using way more than 6 characters), after which I was in my account.
I had back control of my account, yet somehow I felt worse than before.
This is far too common. We, in security, must understand that our job is not making our users’ life a misery with bad security controls. Great write-up, Nishant.
Thanks. Completely agree that security has ignored UX for far too long. Need to enforce (as customers, analysts and even vendors) the viewpoint that Bad UX = Bad Security.