When factors collapse and two factor authentication becomes one.
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
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
dave
May 22nd 2012
1 decade ago
"... should be managed by a industry-wide specification known as the TPM, or trusted platform module*."
* https://en.wikipedia.org/wiki/Trusted_platform_module
... sooner is better.
PC.Tech
May 22nd 2012
1 decade ago
I have been confused in recent years by the proliferation of software tokens, whereby the token is displayed via an application on your computer screen and you need a PIN to display it. In short, you need a PIN and your usual password to gain full access, which in my mind is one factor, not two. ('two' things you know...)
Unless I am missing something, aren't soft tokens like this misleading and defeating the purpose?
Thanks for a good article (as always!)
Daniel
Daniel
May 23rd 2012
1 decade ago