Software token

From Wikipedia, the free encyclopedia

This article or section may require cleanup to meet Wikipedia's quality standards.
Please help improve this article or replace this tag with a more specific message. This article has been tagged since October 2005. (help, talk)

Software tokens are a weaker form of two-factor authentication. Unlike hardware tokens that store the user’s credentials on an external device away from the PC, software tokens run on the PC or on a separate multi-purpose device and they are therefore left exposed to threats such as malicious software attacks and physical attacks.

There are two primary architectures for software tokens: shared secret and public key. In general, time-based and incremental software tokens that rely on shared secrets have proven to be problematic and weak. Typically, the administrator generates a configuration file for each user that contains the username, PIN and the secret. The file is given to the user. If the file is stolen, the token can be cloned. With time-based software tokens, it is possible to borrow the PDA or laptop, reset the clock and generate codes that will be valid in the future. Any software token that uses shared secrets and keeps the PIN (the first factor) with the shared secret (the second factor) in a software client can be stolen and subjected to an offline brute force attack. Shared secret tokens can also be difficult to distribute, since each token is essentially a different piece of software. Each user must get the appropriate secret, which creates an administrative headache.

Some newer software tokens rely on asymmetric cryptography. This architecture eliminates many of the traditional weaknesses of software tokens. The PIN can be stored on a remote authentication server instead of with the token client, so stealing the token does the attacker no good. They must also steal the PIN. Attempts at guessing the PIN can be logged on the authentication server, which can disable the token. Using asymmetric cryptography also simplifies implementation as the token client can generate its own key pair and exchange public keys with the server. Yet software tokens remain dependent on the integrity of the computer they reside on. Though many security risks can be mitigated with asymmetric cryptography the solutions are still far weaker when relying on software tokens rather than hardware tokens, furthermore, it is still not possible to achieve non-repudiation with software tokens.