Types of Security Tokens

The Security Token Wikipedia page doesn’t seem to clearly describe the types of token.

Categories of Security Token

It seems to me that the following categories encompass all security tokens:

1. Biometric tokens – which seems rather pointless to me. Having a device I control verify my biometric data doesn’t seem to provide a benefit. The only possible benefit seems to be if the biometric token verifies the identity of the person holding it before acting as one of the other types of token.
2. Challenge-response devices. The server will send a challenge (usually a random number) and will expect a response (usually some sort of cryptographically secure hash of the number and a shared secret). A challenge-response device may take a password from the user and combine it with the challenge from the server and the shared secret when calculating the response.
3. Time-based tokens (one-time passwords). They will provide a new pseudo-random number that changes periodically, often a 30 second time interval is used and the number is presumably a cryptographically secure hash of the time and a shared secret. This requires a battery in the token and the token will become useless when the battery runs out. It also requires that the server have an accurate clock.
4. Use-based tokens. They will give a new pseudo-random number every time a button is pressed (or some other event happens to indicate that a number has been used). These do not work well if you have multiple independent servers and an untrusted network.

Here is my analysis of the theory of token use, note that I am not sure how the implementations of the various token systems deal with these issues.

1. Biometric security seems like a bad idea for most non-government use. I have seen a retina scanner in use at a government office – that made some sense as the people being scanned were in a secure area (they had passed some prior checks) and they were observed (to prevent coercion and the use of fake eyes). Biometric authentication for logging in over the net just seems like a bad idea as you will never know if you can trust the scanner.
2. It seems to me that challenge-response devices are by far the most secure option. CR is resistant to replay attacks provided that it is not possible to have re-used challenges. If the calculation of the response includes a password (which is performed on some tokens that resemble pocket calculators) then a CR token will meet the “something you have and something you know” criteria.
   One potential problem with CR systems is that of not including the server or account ID in the calculation. So if I was to use a terminal in an insecure location to login to a server or account with data that is not particularly important then it would be possible for an attacker who had compromised the terminal to perform a Man In The Middle (MITM) attack against other servers. Of course you are supposed to use a different password for each account, if you do this then a CR token that includes a password will be resistant to this attack – but I expect that people who use tokens are more likely to use one password for multiple accounts.
3. Time-based tokens have a weakness in that an attacker who can immediately discover the number used for one connection could then immediately login to other servers. One example of a potential attack using this avenue would be to compromise a terminal in an Internet cafe, steal a hash used for logging in to server A and then immediately login to server B. This means that it may not be safe to use the same token for logging in to servers (or accounts) that have different sensitivity levels unless a strong password was used as well – I expect that people who have hardware tokens tend to use weaker passwords.
   Also one factor that will make some MITM attacks a lot easier is the fact that the combination of the hash from the token and the password are valid for a period of time so an attacker could establish a second connection within the 30 second interval. It seems that only allowing one login with a particular time-coded password is the correct thing to do, but this may be impossible if multiple independent servers use the same token.
   Time based tokens expire when the battery runs out. The measures taken to make them tamper-proof may make it difficult or impossible to replace the battery so a new token must be purchased every few years.
4. Use-based tokens are very similar to time-based tokens, it’s just a different number that is used for generating the hash. The difference in the token is that a time-based token needs a battery so that it can track the time while a use-based token needs a small amount of flash memory to store the usage count. The difference at the server end is that for a use-based token the server needs a database of the use count of each token, which is usually not overly difficult for a single server.
   One problem is the case of a restore from backup of the server which maintains the use count database. The only secure way of managing this is to either inspect every token (to discover it’s use count) or to issue a new password (for using password plus token authentication). Either option would be really painful if you have many users at remote sites. Also it would be required to get the database transaction committed to disk before an authentication attempt is acknowledged so that a server crash could not lose the count – this should be obvious but many people get these things wrong.
   An additional complication for use-based tokens comes with the case of a token that is used for multiple servers. One server needs to maintain the database of the usage counts and the other servers need to query it by secure links. If a login attempt with use count 100 has been made to server A then server B must not accept a login with a hash that has a use count less than or equal to 100. This is firstly to cover the case where a MITM attack is used to login to server B with credentials that were previously used for server A. The second aim of this is to cover the case where a token that is temporarily unguarded is used to generate dozens of hashes – while the hashes could be immediately used it is desirable to have them expire as soon as possible, and having the next login update the use count and invalidate such hashes is a good thing.
   The requirement that all servers know the current use count requires that they all trust a single server. In some situations this may not be possible, so it seems that this only works for servers within a single authentication domain or for access to less important data.

Methods of Accessing Tokens

It seems that the following are the main ways of accessing tokens.

• Manual entry – the user reads a number from an LCD display and types it in. This is the most portable and often the cheapest – but does require a battery.
• USB keyboard – the token is connected to a PC via the USB port and reports itself as a keyboard. It can then enter a long password when a button is pressed. This is done by the Yubikey [1], I am not aware of anyone else doing it. It would be possible to have a token connect as a USB keyboard and also have it’s own keypad for entry of a password and a challenge used for CR authentication.
• USB (non-keyboard) or PCCard/Cardbus (AKA PCMCIA). The token has it’s own interface and needs a special driver for the OS in question. This isn’t going to work if using an Internet cafe or an OS that the token vendor doesn’t support.
• Bluetooth/RFID – has similar problems to the above but also can potentially be accessed by hostile machines without the owner knowing. I wouldn’t want to use this.
• SmartCard – the card reader connects to the PC via Cardbus or USB and it has all the same driver issues. Some SmartCard devices are built in to a USB device that looks to the OS like a card reader plus a card, so it’s a USB interface with SmartCard protocols.

To avoid driver issues and allow the use on random machines it seems that the USB keyboard and manual entry types of token are best. While for corporate Intranet use it seems that a SmartCard is best as it can be used for opening doors as well, you could use a USB keyboard token (such as a Yubikey) to open doors – but it would be slower and there is no off the shelf hardware.

For low cost and ease of implementation it seems that use-based tokens that connect via the USB keyboard interface are best. For best security it seems that a smart-card or USB interface to a device with a keypad for entering a password is ideal.

• [1] http://www.yubico.com/