How should we handle lost tokens?

TB & VW KeysThis has been a topic of discussion over the past week around the office. We are all using TrustBearer Keys with OpenID on a daily basis, and I’m doing my best to not lose or break my key. I finally decided to add my TB Key to my physical keychain. Would you believe it’s not the most expensive item on that ring? That Volkswagen key fob is a salty $180 to replace. I know. Crazy. That’s how much it costs for the dealer to copy it onto another fob. Just the key… Still almost $100!

That cost has been a really good reason for me not to lose my car key. But, it’s going to happen one of these days. And I’ll roll back to using the valet key. So, should we offer a TrustBearer Key backup service? Actually, that’s not possible. At least not with the current configuration of the TrustBearer Key. The 1024-bit RSA keypair is generated on the token, and this key cannot be exported. We could offer an escrowed version in the future… but do you really want us to have a copy of your private key?

Another option, suggested earlier this week, is to allow users to link multiple keys to a single OpenID account. Similar to escrowing the keys, this provides users with a backup. Except in this case, the user is in control. We could implement this in a reasonable amount of time. It provides a decent way for users to maintain high security of their account, and have a backup. But, there’s always the cost. Have I copied my VW key yet? Nope. ($100 for a key?!)

PayPal KeyVeriSign’s Personal Identity Provider allows users to link a One-Time Password token to their OpenID account. I gave this a try with my PayPal Security Key. It worked very well. I really liked the fact that I could recycle my PayPal OTP with VeriSign’s OpenID provider. VeriSign handles forgetting or losing a token with two options: By either using email (default) or SMS to send a one-time PIN. Linking my mobile phone was simple, and even though I’m not sure if it’s more secure than email, I preferred using the SMS method. But, the email option is the default and it cannot be disabled. Wait. I have a hardware token that greatly reduces the chance of someone guessing my password, but my email account is still a backdoor? Yup. I had this same thought when I clicked on the “I don’t have my PayPal Security Key” button when logging into PayPal. I understand that locking users out of their accounts is a bad thing, but any worthwhile malicious hacker is going to attack the weakest link: in this case, an email password.

TrustBearer OpenID works with higher security devices than OTP tokens like the PayPal Security Key. As a user of this service, I expect more than an email password to be thrown as an identity challenge if I lose my token. Is SMS the answer? As I mentioned earlier, it seems better, but I doubt it’s as secure as my non-exportable 1024-bit hardware key.

We could come up with a list of questions to which only the true owner will know the answers. How about 10 questions? 20? How many human-answerable questions are equivalent to the security of the hardware tokens we support? Sure, it’s going to be inconvenient, but that’s the point. I haven’t lost my VW key, because it is going to be extremely inconvenient to replace. But, I will shell out the $100, and go to the dealership (the only place that can copy the key) when I do lose it.

How inconvenient should we make recovering your access?


8 responses to “How should we handle lost tokens?

  1. My impression is that SMS is no more secure than email. Perhaps a little bit tougher for an average person to intercept but I believe a dedicated person would not have too much of an issue. Keep in mind that ultimately they are broadcast by big towers as radio signals in order to get to your phone… A quick search appears to confirm this:

    Article waffles on whether or not the messages are encrypted, and my guess is carriers vary on encryption techniques, with some opting for the cheap way of not encrypting them.

    Recovery is a good question that doesn’t seem to have easy answers…

    Similar to additional devices, what about allowing non-device keys (ie, OpenSSH and/or PuTTYgen keys)… These would be a little less secure, so it might be nice to get some sort of notice when used (ie an email with a “someone just used a non-device key associated with your account”), but the benefits are that such a secondary key could be integrated into a person’s typical backup/recovery plan…

    I think I need some more time to think about this… maybe a better idea will occur to me.

  2. Max, thanks for sending some information regarding the vulnerability of SMS. I’d like to read about any specific attacks on existing SMS authentication systems, like Bank of America’s SafePass, for example.

    We have a working prototype of software-based tokens for TrustBearer OpenID, but we are still hashing out the file system storage specifics and UI workflow. Hardware tokens made things a bit simpler to implement since we didn’t really need to worry about reading and writing to various locations on users’ file systems.

    I’m not sure that most users are ready to accept responsibility for backing-up their keys. This is a big shift in how most of us think about online account recovery today. Perhaps, as a “secure” OpenID provider, we, TrustBearer Labs, need to handle backing-up all of our users’ keys. And, if a user loses his or her token, we mail that user a new token to a pre-determined physical address.

  3. You could address this relatively cheaply by allowing users to chose from a couple of levels of restriction:
    [1] Account recovery that simply resets the account and e-mails (or SMS’s) a URL that enables the user to re-enroll a different token.
    [2] Account recovery where a physical token that is pre-authenticated to the users account is mailed to a previously configured physical address. ( Brian’s suggestion)
    [3] Account recovery is disabled – the user agrees to take responsibility for all recovery. This case would require that they have at least two physical tokens associated with the account.
    You could default to 2 and allow users to either raise or lower the bar to meet their needs. Or simply keep the higher two levels if you wanted to build and maintain a reputation as a secure OpenID provider.

    As far as option [3] is concerned I think that the concept of using multiple physical keys linked to one account is pretty intuitive. My car keys (European Ford – I assume they use the same system elsewhere) work in a similar way – I can add new ones myself and I can even revoke lost keys provided I still have at least one working key. I’ve no idea how strong the actual protocol they use is but the principle is simple enough for most people I’ve talked to about it to understand.

    For the lower security option [1] case I don’t think that there is currently any real alternative for the disaster recovery process for general purpose Internet users to having them respond to pre-agreed challenges (the “What’s your Mother’s Maiden Name?”, “First School?”, “Favourite Place?” sort of thing) even though those are often easily attacked by social engineering and\or research. However when they are used in combination with an out of band communication channel they are reasonably robust for cases that don’t require ultra high security e.g. sending the challenge via a known phone number. Max’s point about SMS is probably true but SMS remains a lot harder to compromise than e-mail and in most cases users will not need or want the hassle that goes with genuine high security.

    Max’s final comment about using software keys (like OpenSSH\PuttyGen or just OpenSSL) is another good alternative. Those could work but I would think that InfoCards\CardSpace would be a better fit as they wrap the rather unfriendly key handling stuff in a relatively user friendly interface and those could provide a good disaster recovery option if those technologies were more common. Both of those concepts have some way to go before they will be sufficiently widespread and understood to be a useful alternative for most people though. In many ways they fit a niche that competes with physical tokens but that is also what makes them useful as an identity assertion solution for disaster recovery in a situation like this.

  4. Ideally, this authenticated comment would have been openid enabled “-)

    Now that the trustbearer portal can be linked up to the Rapattoni infrastructure, the combination has everything the VeriSign PIP has. 2 factors OTP tokens, and SMS support. Its also a faction of the price (to US Realtors).

    One thing Id love to do is experiment on trustbearer with RSA’s latest generation of SID900 tokens. These adds challenge response, to the classical tokencode. The result is “signatures” via OTP, since the challenge used in generating the (OTP timestamped) response can be linked cryptographically to the material being authenticated – such as this text.

    Even more fun would be to add yet more factors of assurnance. Above and beyond the SID900 assurance, we could still be requiring the user to type in the tokencode at a form prompt.’s keystroke biometrics could be guaging the likelihood that the true user is doing the typing, of the (public) tokencode. All it takes is deploying a flash control on the IDP portal site, for tokencode entry.

  5. Pingback: Backup your account with multiple tokens « OpenID with Strong Authentication

  6. We’re already carrying “backup” tokens around with us all the time; hardware encryption tokens.

    * The SIM card in your phone.
    * The chip on your bank cash card (e.g. Visa Debit in Europe).

    While the SIM card has the potential to become a primary token, the bank card smartcards can be viewed as decent emergency backups. A scheme involving bank cards would require ATM organisations (e.g. Link in the UK) to provide an additional service over and above cash withdrawal and balance transfer.

    First, you’d register your bank card as a backup token. Following a token loss, on the web you could make an assertion like “I’ve lost my token, I want to register a new token”. Then, a quick trip down to the ATM would allow you to approve the assertion.

    I wonder if there’s any appetite from the banking
    groups to look at this? I doubt it.
    I think it would be something that they could actually utilise themselves for online banking security. In the UK, we’re being given “CAP Authentication” tokens to use in conjunction with our bank cards when performing online bank transactions. The pain is that when you don’t have a CAP device to hand, you can’t authorise transactions. Allowing transactions to be performed online then authorised at an ATM is a nice touch, but probably not enough of a benefit for banks to consider.

  7. As a final note, I would hope that TrustBearer will continue to insist on hardware token authentication and resist *any* pressure to make it easier to work around a lost token. Any email or SMS based workarounds compromise the unique selling point of TrustBearer, proper security. The ultimate workaround is to get a new “identity”. That’s not as bad as it sounds, your OpenID represents your identity not you. The couple of times in my life when my work Windows username was changed didn’t result in me disappearing from existence ;)

  8. Hi, this weekend is fastidious in favor of me, because this point
    in time i am reading this wonderful educational piece of writing here at
    my home.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s