This 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?!)
VeriSign’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?
stevepepple
corcordt
Taylor Venable
Brian Kelly
harningt
cpenn
rsteger
5 responses so far ↓
Max Battcher // February 23, 2008 at 2:02 AM |
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:
http://redtape.msnbc.com/2007/03/snagging_text_m.html
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.
Brian Kelly // February 23, 2008 at 1:01 PM |
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.
Joe Mansfield // February 26, 2008 at 6:46 AM |
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.
Peter Williams // March 10, 2008 at 2:09 AM |
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. biopassword.com’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.
Backup your account with multiple tokens « OpenID with Strong Authentication // April 22, 2008 at 10:16 AM |
[...] We realized that it was only a matter of time until someone lost a token, or ran it through the washing machine. There was some discussion on the blog around how we should handle this case of lost tokens. Some ideas included sending a SMS message as a one-time unlock, answering a series of Q&A pairs and mailing a token to a pre-determined physical address. While all of these recovery methods are interesting, they either reduced security (SMS, Q&A) or added privacy implications (mailing a recovery token). [...]