Hack the Gibson #90


Read the reason for these posts. Read Steve Gibson’s response.

Towards the start of the show Leo mentions that SSL certificates used by the sites to authenticate themselves to the users are single-factor. And this is true, however one has to add that there is nothing wrong with single-factor authentication as long as good security practices are followed, that is (for passwords for example):

  • Long passwords are used
  • Passwords are not easily guessable
  • Passwords are stored in a way that it is hard for attackers to access them
  • Passwords are transmitted in a way that it is hard for attackers to intercept them

The problem is that it is much easier for a company which has much more (financially speaking) at stake that a single user to implement and adhere to these measures (and even so, in many cases they are unable to), than for users. Also, there is a psychological problem of the user not being in business mode when doing the purchase (that is not concentrating on the rules s/he should follow) when doing an online purchase for example, while the company (or more precisely the employees of the company) is more likely to be in business mode. So there is nothing wrong with single-factor authentications as long as good practices are followed.

Steve mentions the fact that weak authentication can mean plausible deniability, however fails the mention the process of creating an audit log (which in IT means the recoding of the details of the actions) or event correlation (which means piecing together information from multiple sources) which do limit these attacks.

As a counterexample for the example given by him (that you can say that someone else logged on as you if you had a weak password): if you have the IP addresses recorded in the audit logs from where the connection originated, that can increase or decrease the probability of that claim (mind you, in security you can never claim to prove or disprove anything with a 100% certainty because there are may ways – for example the attacker might had proxied a connection through the users computer). Or if you had event correlation and you knew that the user was in one town (based on his badge being scanned at entry in the building) and the login came from an other town (based on IP Geolocation), you knew that that was a possible attack.

The following generic discussion is accurate as far as I can tell. And this is the strong part of Steve – making general presentation. However when going a little deeper he often times makes mistakes or gives confusing statements.

Like for example in the discussion of the Bank of America SiteKey. Disclaimer: I never used BofA and didn’t study the SiteKey method, however it is clear that from the following three claims (all of which were made during the discussion) only one can be true:

  1. The displayed image is based on your IP
  2. The displayed image is based on a cookie (or flash cookie) stored on your computer
  3. The displayed image is based on your username, which you’ve entered before the image becomes visible

Most probably it is the second option (because it would be non-sensical to base the system on your IP address – you might have dynamic IP for example which changes from time to time without your intervention – and but still displays the symptoms which were used to justify it – the fact that when you have a different IP it doesn’t show – probably because you’re on a different computer which doesn’t have the cookie).

Update: I’ve forgot to mention that they discuss in this podcast also a version of the RSA token which could be installed on a mobile phone or even on the computer. While this has some usability advantages (such as not requiring an extra device which has to be carried around and may be lost), it has the definitive disadvantage that it can be copied! In fact what makes items such as the RSA tokens unique is the fact that the unique data in them (the encryption key / random seed / serial number) is hardcoded and can not be read easily. As soon as this data becomes known for a particular user, theoretically her token can be emulated perfectly. While I’m sura that RSA did a great job preventing the leakage of this information through the generated numbers (that is, you most probably can’t guess it by observing the generated numbers, or if so, you would have to observe a very large amount of numbers), but as soon as the data becomes available to other programs, the risk for it to be stolen is greatly enhanced.

, , ,

2 responses to “Hack the Gibson #90”

  1. It’s both #2 and #3 – the image is supposed to authenticate the server to you, and you’re supposed to authenticate yourself to the server using both your cookie and your password, making it (in their words), two-factor.

    Only problem is that it’s not two-factor. At best, it’s 1+1 factor. If you can copy the “something you have” easily, it behaves (from a security perspective) much more like “something you know.”

    I blogged more about this here:

    http://blog.phonefactor.net/?p=15

  2. Hey Steve, any updated opinions on PhoneFactor, especially relative to thin clients like terminal services? For example, how about a pin-based solution entered into the phone?

Leave a Reply to Steve Dispensa Cancel reply

Your email address will not be published. Required fields are marked *