on-the-security-of-software-tokens-for-two-factor

Posted by:

admin 15 years, 11 months ago

Securology has a post about RSA's software tokens. In it, two key issues with are raised, one is specific to tokens that use symmetric encryption such as the RSA software tokens:

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).

Note that this is not an issue with WiKID's software tokens as we use public key encryption. The private key remains on the device and only the public key is transmitted. It is the out-of-band method of verifying the user's registration code that matters for WiKID. This could be done over the phone or via an application which uses some existing trusted information or credentials. (We protect against a man-in-the-middle attack in this process by hashing the registration code with the WiKID server's public key before presenting it to the user. Thus, if someone is trying to impersonate the server, the registration with the real server will fail.)

The second issue is a more general concern with software tokens:

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.

Malware is huge and growing problem. No doubt about that. It is also increasingly sophisticated and most malware today is typically not a single use piece of software, rather it is a suite of tools. For this reason, if malware is on the PC, once the PC is on your network, it is likely that a trojan horse is on your network too, no matter the authentication method. My inclination here would to invest the savings from going with a less expensive two-facto authentication system in a defense-in-depth strategy against malware that includes gateway scanning and validating updated anti-virus databases before a user is granted access to the network.

There is another risk here - which seems to go unmentioned too frequently - network-based man-in-the-middle attacks. There are a few reasons why these should be of more concern:

• The increased usage of SSL-based VPNs which use easily-ignored browser certifcates.
• The increased usage of WiFi, often in public settings.
• The increased instances and sophistication of DNS-Cache attacks

Granted, most DNS-Cache attacks are currently targeting online banking, but that will evolve as with all attacks. I bring this up, because the WiKID PC-based tokens also perform https mutual authentication. If an HTTPS url is associated with a domain, the WiKID software token will fetch the certificate at that URL, hash it and compare the hash to the one downloaded from the WiKID server with the one-time password. If the hashes match, the token will launch the default browser to URL. (This process is similar to SSH key verification.).

So, if you are using corporate laptops for mobile users and feel confident in your anti-malware solutions, but suspect (well, how can you know that they won't?) that your users will be connecting to your SSL-based VPN or extranet from WiFi hotspots, you are better off from a security perspective deploying software tokens that include mutual authentication than using hardware tokens.

• Tags:
• Two Factor Authentication,
• Authentication Attacks,
• WiKID,
• Mutual Authentication,
• Wireless, cellular, mobile devices,
• pci

Share on Twitter Share on Facebook

• ← Can the WiKID Server and/or Token be embedded?
• on-the-short-tenure-of-cisos-and-low-frequency →