SANS ISC: When factors collapse and two factor authentication becomes one.

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

The benefits of two factor authentication are pretty much Security 101 material. And we are also told, that two factors are more then "password 1" and "password 2". RSA for example, one of the leaders of two factor authentication, defines this pretty nicely:

"Two-factor authentication is also called strong authentication. It is defined as two out of the following three proofs:

• Something known, like a password,
• Something possessed, like your ATM card, or
• Something unique about your appearance or person, like a fingerprint."

There are a number of ways these factors can collapse. For example, for a one-time password token, the user typically needs to remember a password, or a PIN, as second factor. Users tend to write this password on the pack of the token, collapsing the factors. Now you only need to "possess" the token. In a more elaborate case, I ran into a user who had a webcam at home pointed at the token (he always forgot his token at home). Now all you needed to access the system was "something known" (the URL of the webcam and the password).

Tokens themselves pose a different threat to collapse factors. Tokens operate by calculating a hash of an internal secret ("seed") and either a timestamp or a counter. You may not know the seed, but someone else may. This issue has come up with the recent breach of RSA that may have lead to the leak of these seeds. The "seed" should not be directly related to the serial number printed on the device, but in the RSA case, it was alleged that the stolen data included some form of lookup table like that.  RSA's algorithm to calculate the token value had already been leaked years earlier. Of course in particular for software token, the algorithm can be reverse engineered. Evidently, someone now managed to do just that, and to be able to retrieve the seed value from the software token  [3]. Physical tokens are usually hardened to prevent someone from stealing the seed value, in particular to do so undetected. In many ways, a "token" is a secret that you don't know. 

What should you do about all this?

- know the limitations of two factor authentication and educate your users. They aren't the end of password attacks, but the make them substantially harder.
- stolen or lost tokens need to be deactivated immediately. This includes soft tokens. Soft tokens need to be invalidated even if the device is later recovered.
- If you are auditing an organization, watch for "collapsed factors"
- Some two factor authentication systems, like for example the standard based time based and HMAC based one time password systems [4][5] usually expose the seed during setup. It is also typically rather easy to "clone" tokens in these settings (e.g. Google Authenticator uses TOTP). You may want to set up the token for users, or at least ensure that the seed is transmitted and entered securely.

[1] http://www.rsa.com/glossary/default.asp?id=1056
[2] http://www.theregister.co.uk/2011/03/18/rsa_breach_leaks_securid_data/
[3] http://arstechnica.com/security/2012/05/rsa-securid-software-token-cloning-attack/
[4] http://tools.ietf.org/html/rfc6238
[5] http://tools.ietf.org/html/rfc4226
 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter