I appreciate my bank's effort to beef up security. But my story illustrates why security tools that aren't ready for prime time may do more damage than good.
How can a bank — or any organization — become less secure in its attempts to become more secure? Let me tell you how.
Security must do two things: Protect and enable. If your security doesn’t enable people to do what they have to do, they will inevitably circumvent it. And that is the path to perdition (and hacking).
Security often fails because people who design security are much better at throwing up roadblocks than they are creating pathways. Both are equally important if a security scheme is to work.
This month brought yet another story chronicling the theft of millions of passwords by hackers, once again highlighting the importance of implementing “not-just-passwords security” at places that really matter.
How two-factor authentication works
Still, I’m about to turn off two-factor authentication at my bank, right at the moment when everyone seems hell-bent to turn it on. Why? Because it doesn’t make me safer if it doesn’t work; it just prevents me from accessing my money.
I’ve run into classic 21st century red tape headaches with my bank recently as I try very hard to use its two-factor authentication scheme. I often don’t like single-anecdote stories, but occasionally they illuminate larger problems so perfectly they are worth telling. So here goes:
A quick review: Two-factor authentication adds a strong layer of security to a service by requiring two tests be met by a person seeking access — a debit card and a PIN code, for example, representing something you have and something you know. Online banks and websites are slowly but surely nudging everyone towards various forms of two-factor authentication, because it really does make life harder for hackers.
Most of these two-factor forms involve use of smartphones, as they have become nearly ubiquitous. Log on to a website at a PC, confirm a code sent to your phone. Something you have (the phone) and something you know (the password). Simple, but elegant, and far harder for bad guys to crack.
And it’s great, when it works. But what about when it doesn’t work?
A simple glitch
Here’s a simple problem. Consumers get new phones all the time. If the code is tied to the physical handset, a new phone means the code doesn’t work any longer. What then?
Turns out this can be a really vexing problem.
I’ve been a USAA banking customer for decades. The financial services firm has ranked atop customer satisfaction surveys seemingly forever, and for good reason: It really does take good care of members.
At least it did, until it tried to implement two-factor security. I try not to be hypocritical, and follow my own advice, so I turned on USAA’s flavor of two-factor pretty early on. It’s a solid design: A Symantec app loaded onto your smartphone offers a temporary token — a six-digit code — that changes every 30 seconds. The token is tied to the physical handset. Only a person who knows your PIN and can access the token on that handset can log on to the website. You can see all the layers of protection that creates.
Sure, it’s a tiny hassle to pull out the phone every time you want to log on to the website — a larger hassle if your phone battery is dead. But that’s a fair price to pay for security.
However, the hassle becomes immense when it becomes time to change handsets. So immense that as I type this, I cannot access my bank … and have no idea when I will be able to do so. (UPDATE: I was able to fix my login woes 24 hours later.) And that’s happened twice to me in the past year. Why? Chiefly because USAA is not set up to deal with the problem of new handsets.
To review: When I tried to access the website it demanded a token from my phone — a token that was no longer valid because I had a new phone. When I tried to use the phone’s app to access my accounts, USAA asked for a password because it didn’t recognize the phone. I didn’t have a password, I had a token — an invalid token. You get the picture.
All that is a predictable technology hiccup that’s not the end of the world. The real problem came next.
The difficult path to a fix
A call to customer service seemed to be my last available option, but that was dismal, too. At various times I wasn’t able to get through to customer service phone lines. What’s much worse, however, is what happened when I did get through.
People change phones roughly every two years, so this new handset problem must come up often enough. Yet it’s obvious to me that USAA operators are not ready to handle the problem when consumers call. Each time I have reached an operator, I had to spend a lot of time explaining the problem — and remember, I do this for a living. The first successful call today, the operator merely changed my mobile application login settings after putting me on hold for minutes. When I protested that, she said she had to transfer me to a special department, and then the phone went dead.
After a second call and wait, the operator was sympathetic, but put me on hold quickly and wasted a lot of time trying to set me up with a new phone number. It took a while before I could convince her that “new phone” meant “new handset” not “new number,” a mistake I will correct in future calls. We eventually agreed that all I needed was someone to turn off two-factor and issue me a temporary password so I could go in and re-establish the connection between my handset and my account. But after another long hold, and transfers to two other operators, I was told that, sadly, they were having trouble issuing temporary passwords and asked if I could call back in an hour or so.
I’ve left out many steps in this saga. At each stage, of course, I was subject to strict authentication questions. That’s fine — I was asking for a new password, after all. But at the end of my fruitless journey through tech support, when I asked if I could somehow get express treatment when I called back just to find out if I could get a temporary password, I was told, “no.” So I will have to, once again, convince a primary operator of who I am and that I am having token problems and that I need a temporary password. There is obviously no “token problem” script, ready for my problem.