Limitations of One Time Passwords

Recently a man sued AT&T because his one time password was sent to the wrong phone, causing him to lose $24M in “cryptocurrency.”  To punish them, he asked for $200M in punitive damages.  This led to headlines talking about the “dangers” of relying upon SMS to deliver one time passwords.

These are not so much ”dangers” as they are ”limitations.” ”Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.” All security measures have limitations. Perfect security has infinite cost; we must not let it become the enemy of good security.

While one time passwords, whether sent from the server or generated at the client, are orders of magnitude more secure than reusable passwords, they still have limitations.  They must be properly associated with the user or his account.   Like most security measures, and as in this case, this association is vulnerable to social engineering attacks.

Some of you may have tried to register a new SIM or move an existing phone number from one device to another.  You can testify that it can be a pain; the carriers have stringent security procedures in place to resist fraudulent changes to your account. However, they have hundreds of agents handling provisioning requests and they are trained to be customer friendly. In pursuit of this, they can be expected to make mistakes. That is a limitation of using your phone and its number as part of your authentication scheme.

Note that if you do not get a one time password, or a phone call, or even a paper bank statement that you are expecting, you may have been compromised. Note also that the carriers are not the only targets of these ”social engineering” attacks. The attackers may try to get your account holder to change the phone number, e-mail or street address in your account record from your number to theirs. That is why responsible account holders will send you an out-of-band confirmation of all changes to your account record to both the old and the new address. Even hard tokens may be vulnerable to these attacks because the account holder must be able to respond to lost tokens by allowing you to register a new token. Again, not so much a danger as a limitation. Keep in mind that just twenty years ago, the scam was to request a postal address change.

While I use SMS for Google, Dropbox, PayPal, Amazon, my credit union, and my banks, I use a token for my brokerage and retrirement accounts. Note all of these offer me choice of SMS or tokens. ”Horses for courses.” Rest assured that I would not use SMS for $24M. In fact, I would never put all that in one account.

Even as users, we need to know the limitations of the things that we depend upon for security.  As security professionals, responsible for choosing, applying, and operating these mechanisms, it is mandatory.

The Use of SMS for Strong Authentication

NIST and others have discouraged the use of SMS for strong authentication.  This is another case of the perfect as the enemy of the good. 

First, strong authentication using a one time password sent via SMS is dramatically more secure than a replayable password. Second, if you get a one-time password when you ask for it, you are safe.

The problem is not so much with SMS but with the (cell) phone number. There is a risk that an attacker can either change the number in your account, to which the one time password will be sent, to a number other than yours, or get the phone company to associate, re-assign, your number with their phone. In either case, you will not get the one time password when you ask for it. In the latter case, you will not even get phone calls. Whenever the cell phone number in your profile is changed, you will get an e-mail message asking you if you really did it.

Carriers have controls in place to resist fraudulent reassignment of numbers to new phones.  However, the large number of agents and their desire to be accommodating, makes them vulnerable to ”social engineering” attacks. 

The difference in risk between a one-time password sent to your phone and one generated on board is small, particularly when compared to the difference in risk between either and a reuseable password.

In certain circumstances, the difference in convenience may be great. I have ten different accounts associated with my cell phone number. If I get a new phone, all my accounts continue to work as they did on the old phone. The number has moved to the new phone. If I used an on-board password generator, not portable to the new phone, I would have to register the new password generator with each of the ten accounts. I have to do that by calling support, authenticating myself, and registering the new generator. Until I have done that, I cannot logon to or use the account.

If you think about it, the real risk is in provisioning of the phone number or the registering of the on board generator (e.g., VIP Access, Google Authenticator, RSA SecurID Software Token).