Fine's Home
Bear with me, as I try to figure things out I'm going to categorize them in my own way, and for better or worse will probably end up inventing some of my own terminology - I'll try to make it clear when I'm doing that. For one thing, I'm going to use "OTP" to refer to both individual passwords, as well as the overall technology.
Initially, OTP was developed for people to use in non-secure environments, e.g. telnet logins when ssh wasn't available. Because of this people have it in their heads that OTP is only used in such cases. But in our modern world, hackers have become very adept at trapphing ssh passwords, via key-logging, and replaced or front-ended versions of ssh, su and other software that requires passwords. Today, even though you are using ssh or other secure lines of communication, OTP still makes a lot of sense, and can enhance your security considerably. Where I work, we've certainly had our ssh passwords compromised through a variety of methods.
In other words, OTP is still for non-secure environments, but our definition of "non-secure" has changed considerably.
The first OTP approach is "time-synchronized". Ever second, or minute, or whatever arbitrary period of time, counters on both the server, and on your device increment, and a new password is in use. Typically there is a window, where X older and Y newer passwords will also be accepted. This is done so the time synchronization doesn't have to be perfect, and also because it takes slow human beings a bit of time to read and enter the OTP.
The second approach is what I'm going to call "lockstep-synchronized". Each time you generate a new password on your device, it increments it's own internal counter, and each time you actually log in, the server increments it's counter. Typically, the next X passwords will be accepted, so things can be a little bit out of sync, and the server can automatically resyncrhonize.
The third approach is "challenge-response". In this case, it doesn't matter if the passwords are generated in order or not (they often still are, for other reasons). The server picks a password, and when you authenticate it offers you a "challenge", which is really just telling you to look up password #X. You enter X on your device, and it generates password #X.
The fourth approach is completely different. With this approach, your device is a communications device, usually a pager or cellphone. When you attempt to authenticate, the system sends your password to your device, and you use the password to log in. No seeds are required, the passwords can be completely random. This is generally referred to as "SMS-OTP".
What I've described so far is not two-factor authentication. An OTP is just a single factor, it's (more or less) something you have (like a cell phone, or a dedicated OTP calculator). To make this two-factor, a secret password that you know is also used somehow in the OTP authentication. One way simple way is that when you enter your OTP to login, you also enter your secret password right next to it. I'm going to call this a "PIN". Another method is that you would need your secret password to unlock the device you are using to generate OTPs, which I will refer to as a "passphrase". In other words the distinction between these names as I'm using them here is that a PIN is a plain password used together with an OTP, while a passphrase is a password used to obtain an OTP.
Of course PINs don't have to be numbers, and passphrases don't have to be phrases. But over time "passphrase" has become a common way to refer to passwords that unlock other security mechanisms. So yes it's kind of arbitrary terminology, and I'm making this distinction artificially. The literature out in the world sometimes matches what I'm doing here, but not always. If you have a better suggestion for terminology, please let me know.
If your device is a printed list of passwords, then a passphrase is fairly impossible (although one could print the list "wrong" such that you had to add a number to every password, or something like that).
PINs can be snooped as they are typed, and at first glance may seem to ignore the point of OTP. But if we profile typical hacker scenarios, it makes more sense: someone may find your device, and may be able to identify the account and attempt logins, but can't get in without the PIN. And someone may find your PIN with a keylogger. But they won't have your device. The opportunistic hacker would never put the two together. Only a stalker, targeting a specific individual, might be able to eventually compromsie both, but this is a very rare profile for a hacker, and not a significant concern for most sites.
Passphrases are generally safer than PINs, because they aren't sent back during authentication, so there is less opportunity to eavesdrop. This is not to say it's impossible. Phones can be hacked too, and people can just watch you enter it into a device. But it looks to me like the passphrase approach is generally better.
However I should point out that it's important to think about your device. Ideally devices are fully separate from the computers you use to authenticate. There are applications you can install on your laptop or desktop that let you calculate your one-time passwords directly on the computer. But using these means that a hacker could have one-stop shopping to find your passphrase, and the seed you use to generate your OTPs. The calculator is more ideally only on a separate device.
It should be observed that the something-you-have device can still be characterized as something-you-know. A piece of paper has information that could be copied. A phone has an app with a seed that can be read out and copied. A dedicated calculator has a seed built in, although in that case one hopes that the device is fairly tamper-proof. And of course, the seeds are also stored somewhere on an authentication server, and must be protected there as well.
Even with SMS-OTP, the phone is like something-you-know, because it is possible to snoop phone transmissions. So knowing the encryption method and secret for the text message could be a problem.
With SMS-OTP, it may make sense for the paranoid to use both a passphrase and a PIN. The OTP can only be snooped over the phone network. The PIN can only be snooped over the authentication platform (computer). And the passphrase can only be snooped on the OTP device (cell phone). A security person might still call that two-factor, but for the hackers it's three different things to grab.
Cell phones are a very popular choice now, because so many people already have them, and carry them all the time. There's nothing extra to carry. But phones have some significant disadvantages too. It's probably pretty easy to figure out who owns a cell phone, especially a smartphone. And even to figure out likely account names and hostnames (from any email addresses being used). It's also usually possible (and easy) to extract the seed from the cell phone. For these reasons, if a cell phone is used as the OTP generator, it's doubly important to use a PIN or passphrase.
Dedicated OTP calculators are usually designed to be tamper-proof, and printed papers would certainly not list the seed, and so in these regards both can be considered more sercure than a cell phone.
(In theory, a printed list of passwords could be used to uniquely identify the original seed. If the mathematical algorithm is secure, this should be statistically impractical, but I'm not sure of the current state of the algorithms, and if they've been evaluated for this sort of compromise.)
The primary downside to dedicated OTP calculators is that they cost money, and they are generally associated with servers that cost money too. It's also a bit more of a nuisance to carry them, although most nowadays are very small and can sit on a keychain. This size has a minor disadvantage too though, that most of these small devices have no key entry, and as such can not have a passphrase. A PIN can still be used though.
And, as I mentioned previously, installing a program on your computer that serves as the device is usually a poor choice, because if you're doing two-factor you're making both factors available to hackers in a single location.
If you accidentally generate several keys on your device without using them, your device will become too far ahead of your authentication server, and you will not be able to log in until you resyncrhonize. This might only be accomplished through a helpdesk and a human being. Or a program could be used that can only be run if you are already logged in (i.e. if you are physically present and logged in at a desktop system you could run this program). Or through a web page which uses other means to authenticate you.
Another issue related to syncronization is that you can't easily use more than one device. If you do, then you'd have to remember to use up the same password on all devices to keep them in sync. This sounds like a recipe for confusion and frustration. In theory, you could use paper as a device, crossing off password as you go, and then when you return to your physical device you could sync it to the paper by using up the crossed-out passwords.
This isn't totally a negative, as one could easily argue that it's a benefit to encourage people to use only a single device to generate OTPs, because users will be less tempted to install an OTP generator on their laptop or home system.
Another issue with lockstep synchonization is that with some devices (e.g cell phone apps), the sequence can be reset to the beginning, the server resyncrhonized, and passwords re-used. This is a bad idea, as a hacker who's been logging passwords might notice this, and be able to see which passwords are coming next. OTPs should never be re-used.
If implementing lockstep-syncrhronization on multiple authentication servers, it is critical that they have a way to share the synchronization information. Otherwise multiple logins on one server will cause another server to be too far out of sync.
Depending on how the cell phone stores time, and how the app is written, timezones can be a problem. If the times aren't synchronized to a universal time, traveling to a different timezone can cause your phone to reset it's clock in a way that will ruin the synchronization.
Lockstep has one slight advantage over time, and that is that everybody knows what time it is (despite the song by Chicago). If your seed was compromised, then time-synchronization is immediately compromised, whereas with lockstep syncrhonization, a hacker would still have guess where you are in your sequence (depending on how he compromised the seed - if he got it from the server he may have stolen state information too. This is only a slight advantage though. If the lockstep started at password #1, then the hacker doesn't have to try very many keys in order to authenticate. And once the seed is compromised we shouldn't really hold out hope anyway.
On the other hand, time-synchronization has a significant advanatage in implementation on the server end. If multiple authentication servers are to be used, the servers have to be syncrhonized with each other. For time-syncrhonization, this is probably not a problem, as the servers' clocks are probalby already syncrhonized.
One additional disadvantage is the possibility of reusing passwords. With all the other methods, a password should only be valid once. However (depending on implementation), a time-synchronized password might be re-used multiple times during the login window. This allows the possibility of someone snooping the password on the network and immediately logging in with it themselves.
Time-synchronization is perhaps less well-suited to a paper device than others, as you'd need a long list of times and passwords, and it would need to be updated daily. In certain security situations some might find this attractive though.
If the challenges are in sequence, then this is well-suited to paper devices with lists of passwords. And I see no reason to randomize the challenges, since the challenge is completely public anyway. [Please leave a comment at the end if you see any benefit that I'm missing].
Challenge-response avoids problems of synchronization with the user - if the user's device is operating, they can always respond to any challenge. However, passwords should still not be re-used. If passwords are picked randomly, then a database must be kept of which passwords have already been used. This is a good argument for continuing to select passwords only in ascending order (possibly with gaps). If multiple authentication servers are used, then they still must be kept syncrhonized in some fashion to avoid password re-use.
Ideally this will be used with encrypted messages, together with an app on the phone that can decrypt them. And protecting the decryption key with another password gives you two-factor authentication.
If you lose your pager or phone, you can't log in until you get it replaced. There is no paper list alternative, unless SMS-OTP is implemented with a seed value instead of more random passwords. It probably doesn't make sense generally to use seeded OTP with SMS-OTP, however in the case that SMS-OTP is used as a backup in case some other OTP device has been lost, it might be an acceptable policy.
It may seem counter-intuitive at first to broadcast a password over a wireless phone network, but with proper implementation this may arguably be the most secure.
One very significant problem in any kind of authentication is the man-in-the-middle attack, and OTP is as vulernable to this as anything else. With this attack, the hacker sets up a fake interface for authentication (e.g. a fake web page, or an email phishing attack). Whatever you enter is passed on to the real interface, allowing the hacker to authenticate, and leave you with a failure message. This attack has been successfully used for bank fraud in Europe, where SMS-OTP is a popular way of validating electronic transactions.
The solution to man-in-the-middle is really separate from OTP. Regardless of how you are authenticating, you need a method of insuring that you are communicating with the legitimate service. In the case of ssh, this is provided for by host keys. If they are not as expected, ssh issues a warning. (Unfortunately due to sloppy host key management, people are quite used to seeing this warning and ignoring it.) In the case of the bank fraud, the best practice is to provide transaction information in the message along with the validation password, so the user can see exactly what they are validating (e.g. "transferring $10,000 to Cayman Islands Account *****9489, validate with password '123456'). A concientious user will notice that this is not the transaction they originally requested.
The algorithm used to provide passwords is a possible point of attack. If a hacker collected one time passwords for a period of months and built up a large sample, then it might be possible to guess the algorithm and seed data used. An analysis of this is beyond the scope of this article, but this is theoretically possible for some algorithms. Challenge-repsonse could probably select keys from the sequence in an order designed to frustrate analysis. SMS-OTP could implement truly random password generation.
No comments
|
Fine's Home
|
|
|
Send Me Email |