When factors collapse and two factor authentication becomes one.

Published: 2012-05-22
Last Updated: 2012-05-22 22:42:18 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

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

3 comment(s)

The "Do Not Track" header

Published: 2012-05-22
Last Updated: 2012-05-22 18:06:14 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

A recent proposal, supported by many current web browsers, suggests the addition of a "Do Not Track" (DNT) header to HTTP requests [1]. If a browser sends this header with a value of "1", it indicates that the user would not like to be "tracked" by third party advertisers. The server may include a DNT header of its own in responses to indicate that it does comply with the do-not-track proposal.

The proposal focuses on third party advertisements. It does suggest retention periods for first parties (2 weeks for all logs, up to 6 months for security relevant logs) to remain some compatibility with compliance standards that require specific logging schemes and retention times.

The biggest problem with this standard, aside from user awareness, is the fact that this is all voluntary. There is no technical means to enforce that  a web site treats your data in accordance with the DNT header. Some legal protections are in the works, but as usual, they will probably only apply to legitimate advertisers who are likely going to comply. DNT will only matter if enough advertisers sign up to respect it. It is kind of like the "robots.txt" file, and could even be abused for user tracking as it will make browsers even more "unique" to allow them to be identified without the use of cookies or other tracking mechanisms. [3]

If you are concerned about tracking by third party sites, you need to not load content from third party sites, in particular ads and additional trackers (like cookies). Various ad blockers will help with this. Of course at the same time, you are violating the implicit contract that keeps many sites afloat: For letting you watch my content for free, my advertisers will track you. 

At the same time, users overwhelmingly don't appear to care much about privacy.  The "Do Not Track" header is usually not enabled by default. I don't think many users know about it, or how to enable it. The URL listed below has instructions on how to enable it, and will tell you if it is enabled in your browser. On the ISC website, the number of users with DNT enabled went from about 3.4% to 5.1%, which shows that while DNT adoption in our more technical readership is picking up, it is still rather low.

As far as this website is concerned: We do continuously try to refine our site to "leak less" of our visitors information. For example, we recently switched to a privacy enhanced social sharing toolbar. Our site is also using https for most parts. Aside from the obvious encryption advantage, this will prevent referrer headers from being included if you are clicking on a not-https link on our site.

Our biggest issue right now is the use of Google Analytics, and Google Ads in a couple spots, but I am reviewing these, and am looking for a replacement for Google analytics. Over time, I hope to have less and less third party content on the site that could be used to track visitors wether or not the have the "Do Not Track" feature enabled. 

[1] http://donottrack.us/
[2] http://tools.ietf.org/id/draft-mayer-do-not-track-00.txt
[3] https://panopticlick.eff.org/

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

5 comment(s)
ISC StormCast for Tuesday, May 22nd 2012 http://isc.sans.edu/podcastdetail.html?id=2551

nmap 6 released

Published: 2012-05-22
Last Updated: 2012-05-22 01:22:05 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

nmap 6 was released earlier today, which is a major upgrade to the old version of nmap. One feature that excites me in particular is "full IPv6 support", including OS fingerprinting. 

In order to efficiently scan IPv6 networks, nmap added multicast requests to enumerate live hosts on a network.

For more details, see http://nmap.org/6

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

0 comment(s)

Comments


Diary Archives