The case for supporting one-time passwords in conjunction with regular ones
A few days ago I got a Yubikey. While exploring use-cases for it, it occurred to me that there is a strong case for a mode of operation which is seldom (never?) used by IT departments: using the token while also supporting static passwords for the same services. It is not suitable for everyone, but it is suitable for the security-aware users. I will now introduce Yubikey in a few words, and then explain the purpose of adding support for one-time password to services that already support static passwords, without eliminating the latter.
The Yubikey is a one-time password generator, in the form of a small USB dongle. It is recognized by the PC/laptop it is inserted into (also) as a keyboard, allowing it to enter (“type”) the one-time password directly into the login prompt, just as if the user entered that code manually. This allows the one-time codes to be longer (32 digits) without bothering the user with the need for typing. The scheme implemented by the token is designed to work with an open source server-side, implementing a standard one-time password scheme by OATH. The token also supports a standard Yubico scheme, which can be used against their servers. In this case, the Yubico server is contacted by the application server, over a secure API which is accessible for free, and the Yubico server responds to the application server with whether or not the code provided by the remote Yubikey to the application server is satisfactory. The Yubico server has to be trusted if using this mode, obviously.
This is not the place to delve into the wonders of one-time passwords. Commercial organizations such as RSA and Vasco that sell one-time password generators have been evangelizing on the benefits of one-time passwords for years. A one-time password assures that a usable password cannot be captured by sniffers and key-loggers, and that passwords cannot be disclosed by their users. Nevertheless, I never used one-time passwords myself.
Simply, static passwords, when dealt with properly, are not less secure, and can score higher on the security/usability scale. I have a few web services accessed by me and others. These have very strong, very long passwords, that are static and seldom change. The user has no chance of remembering them, but who needs to remember passwords? These are stored by the password manager, or the browser, and are entered automatically. The password is delivered by the browser to the web server over HTTPS, with a pinned certificate, so it cannot practically be captured, even if I connect from Starbucks. A strong static password which is delivered securely to the server is not less secure than a one-time password, and is way more user-friendly, because there is no extra hardware to carry and use.
Strong static passwords, for people who know not to share them and who use trustworthy machines, are both as secure and more usable than one-time passwords. This model only fails when the user wants to connect from an untrusted computer, rather than from his own. Here two problems emerge: first, as the user does not remember the long password, he has no way of entering it manually when using a browser that’s not his own. Second, even if the password can be recalled, a foreign computer, especially a public one, is the place to get your password stolen, so no sensible person would log in with a valuable password on a public computer.
So how do I work on computers not my own? — I don’t. A web-cafe computer can risk your data other than by stealing your passwords, simply by storing copies of what you do. But moreover, this use-case is not strong enough nowadays. Every typical knowledge-worker has at least one laptop, plus a tablet, a smartphone, and/or other private computing devices. This makes the need to work on a public computer rather rare. The last time I recall using a hotel PC was just to print a boarding pass, since I did not have a printer connected to my laptop. One other case was at a facility that did not allow you to bring your own laptop, but which provided you with an Internet-enabled PC of its own. These situations were ones in which I wished I had a one-time password token to connect to my e-mail server with.
I will never trade the everyday convenience of smooth hardware-free login, for the once-a-year occasion in which I need to use a one-time password. If I had to choose, I would have kept my way and not use public computers ever; but I get to have both. All my application servers now are coded to accept either passwords. I actually changed the applications so the same “password” field can either accept the long static password, or a Yubikey password (that has a recognizable form), without any prior notice, and treats them alike. So, when I am at one of my two offices, or using my laptop/smartphone, the long static password is sent and I can leave the Yubikey at home. When I happen to use a friend’s PC, or a hotel one, I just enter the Yubikey one-time password in that same field, so not to divulge the static one. So far, it works.
Display comments as Linear | Threaded