Something you knowPhysical hardware tokens, like RSA's SecurID, fall into the second category of "something you have". Software tokens, also like RSA's software SecurID, pretend to fall into that same category ... but they are really just another example of "something you know".
Something you have
Something you are
Physical tokens are designed to be tamper resistant, which is an important property. By design, if a physical token is tampered, the internal storage of the token's "seed record" (symmetric key) is lost, in an attempt to prevent a physical attacker from duplicating the token. [Note the words "tamper resistant" not "tamper proof".]
Soft tokens, however, do not share this property. Soft tokens are comprised of two components: 1) the software application code that implements the one time password function and 2) the seed record used in the application to generate the one time password function's output.
"Perfect Duplication" is a property of the Internet/Information Age that is shaking the world. The Recording/Movie Production Industries are having a hard time fighting perfect duplication as a means to circumvent licensed use of digital media. Perfect duplication can be a business enabler as well, as it is with news syndication services that distribute perfect copies of their stories throughout the far reaches of the world in a matter of seconds. In the case of soft tokens, though, perfect duplication is a deal breaker.
Soft tokens are designed to be flexible. It's difficult to provision a hardware token to an employee halfway around the world the same day of the request, but with soft tokens provisioning is a piece of cake. Likewise, it's easier to recover soft tokens when that same employee is terminated. Soft tokens run on virtually any platform. RSA supports everything from Windows Desktops to Browser Toolbars to Mobile Devices-- all you need to do is import the seed record.
There's the rub ... Distributing the seed record requires a confidential channel to ensure that it is not perfectly duplicated in transit. Distributing seed records to many of the supported platforms of soft token vendors involves plaintext transmission, such as sending the seed record as an email attachment to a Blackberry client. An administrator may provision the seed record encrypted using an initial passphrase that is distributed out-of-band, but it is common practice for seed records and initial passphrases to be distributed side-by-side. Whereas a physical token can only be in one place at a time, a soft token could be perfectly duplicated by an eavesdropper, even complete with its initial passphrase (especially when it isn't distributed out of band). If Alice receives her soft token and changes its passphrase, Eve could keep her perfect copy with the intial passphrase or choose to change the passphrase-- either way, the back end of the one-time-password authentication system will receive a valid token code (time value encrypted with the seed record).
Likewise, a soft token employed on a malware-ridden remote PC could have its stored contents uploaded to an adversary's server, capturing the seed record. If the malware also captures keystrokes (as software keystroke logging is so common these days), then another opportunity for a perfect duplicate exists. Soft tokens are vulnerable to severe distributed key management problems. Bob (the administrator in this case) cannot know if the one time password was generated by Alice's soft token application or Eve's perfect duplicate.
In short, a soft token can prove a user "has" the token, but it cannot prove the user exclusively has the only copy. Therefore, soft tokens are not truly "something you have"; they are "something you know" (i.e. the passphrase to unlock a seed record).
For organizations seeking soft tokens as a method of achieving multi-factor authentication, a password plus a soft token is simply two instances of "something you know". Thus the organization must ask itself: "Does the complexity of properly distributing seed records in a secure channel as well as the expense of managing and supporting the software token application code really provide sufficient benefit over a simple--yet strong-- password only method?" My prediction is the answer to that question will be: "No, it doesn't".
UPDATED 12/11/2007 - Sean Kline, Director of Product Management at RSA, has posted a response [Thanks for the heads up]. Perhaps we will have some interesting dialog.