More on the Security of Software Tokens

Posted by:

admin 12 years, 7 months ago

A long time ago, I had a blog post discussion with Securology about the security of software tokens. Since then there has been a massive shift away from hardware-based tokens. A recent post on sensepost about cloning RSA software tokens will rekindle this discussion. Indeed, this morning I discussed it on twitter with boB Rudis and Rafal Los

The sensepost research is excellent. However, when you think about it, the attacker needs to own the machine and be able to enumerate the SID from Active Directory. This means that the computer has been lost or stolen or compromised with malware.  In the lost or stolen scenario, the attacker still needs to get the PIN, so it the equivalent of a lost hardware token.

The most dangerous attack would be malware that included a key-stroke logger. If a machine has malware on it, then there are a number of possible attacks, including stealing information from the session after authentication - a valid attack path against hardware tokens too.

The truth is that this post demonstrates how hard an attack against two-factor authentication is. Compare it to this attack: I purchase a list of corporate email addresses and passwords that have been stolen from a third party site. Or: I phish your user. For a detailed view of the risks, read @hrbmstr's post New SecurID Soft Token Cloning Weakness : What’s The Risk?. Further, as I always argrue: spend the money you save by switching to software tokens on more defense in depth.

If you are particularly concerned about critical data or infrastructure, you can lock it down with two-factor authentication using a separate WiKID domain that requires a smartphone token. So, the users logs into the VPN with PC token. Then to login to the super-secure critical infrastructure a second OTP is needed from a smarthphone token. The attacker must now compromise the PC and the smartphone, again raising the bar.

(For the record, WiKID uses a standard pks12 file to secure our software tokens. The 'locked' tokens pull information off the pc, typically the CPU identifier or MAC address and hash it and send it to the server. Suggestions on improvement welcome.)

Updates

• Dan Kaminsky says there is nothing 'remote' about the attack.
• It occurred to me that this convoluted protection setup is not-cross platform in the least. That may be one reason RSA still has no Windows Mobile 7 token while we have had one for months.
• Looks like RSA included a link to us in a customer communication. Can one of their customers confirm how much less expensive WiKID is?

Further updates:

In response to RSA's response and other comments, Sensepost has an update.

• Any token system can be attacked via the registration process. Relying on unencrypted email is a bad idea, but we defer to our customers on that. Our API offers more secure methods, including allowing users to register themselves based on Active Directory credentials.
• WiKID does not use "a pseudo-random number generation algorithm that is based on a "secret value" and is therefore not susceptible to this particular attack. We use public-private key pairs (asymmetric encryption) that are generated on the device and exchanged with the server. So WiKID does not have a copy of any seed.

• Tags:
• Authentication Attacks,
• Two Factor Authentication,
• WiKID

• ← Accidental Rugged Devops
• Article in [IN]Secure magazine: Adding two-factor to Google apps →