Two channel authentication


I’m no Bruce Schneier, so I welcome the comments of any more informed and/or more intelligent readers (which shouldn’t be too hard ;-)).

Two factor authentication is the buzz these days, it’s the silver bullet of the security industry. To provide a short explanation (which will almost certainly leave out essential facts and get others wrong :-p):

To prove your identity to the other party you can use several factors. Usually factors are categorized in three groups:

  • Something you know (and hopefully only you know :)) – like a password, date of birth, SSN, etc
  • Something you have – like and RSA token, smart card, etc
  • Something you are, also known as biometrics – fingerprint readers, iris scanner, etc.

The basic premise of two factor authentication is that providing two factors from different groups (so an user name and password is not two factor!) increases the trust.

The thing I want to discuss is the way the authentication data goes from the user to the server, the channel through which the information flows. Why is this important? Because communication channels have their own weaknesses like replay attack (where the attacker captures the data – without necessarily being able to interpret it – and resends the exact sequence later) or man-in-the-middle attack. The most frequently used communication channel (HTTP over TCP/IP) is very vulnerable and even protocols which deal with data in transit (HTTPS) can not (and are not designed to) deal with endpoint security. To give a possible attack scenario:

  1. The user goes to a website (lets say over HTTPS)
  2. She enters her username and password
  3. She uses her finger with a fingerprint reader to create a hash that uniquely identifies her finger
  4. She sends all the data to the server for authentication
  5. However, there is an information collecting software (trojan) running on her computer, which captures and relays all the data before it enters the HTTPS tunnel
  6. Now all the attacker has to do is to replay all the data, including the fingerprint hash, without even needing a fingerprint reader (the existence of which the remote server can not check, it can only check that it was supplied the correct hash)

One of the problems in this scenario was that the channel (or more precisely one of its ends) got compromised. PC’s (and Macs too :-)) are relatively easy to compromise because they were built as general purpose computers. However if one of the factors was transported over an other channel, it would mean that the attacker would need to listen in on two channels. This is what I would call Two factor / Two channel authentication.

What attributes would such a channel need? It should be as widely accessible as possible and should be safe (to the extent possible) against spoofing. The (cell) phone network is something that comes close to this. So here is a possible implementation of such a system using the cell phone network:

  1. When the user registers on a site, she gives her cell phone number
  2. When she needs to log-in, she supplies her username and password
  3. After a very short time her cellphone rings, she picks it up and presses #
  4. Now she authenticated using two factors (something she knows – the username and password – and something she has – her cellphone) and two chennels!

Something like this already exists can be used for free by everyone in need to add a second factor to the authentication: PhoneFactor. (Disclaimer: I have no relations with PhoneFactor or anyone involved with it, I just think that it is a very cool idea).

Some issues with this method:

Can’t the attacker just specify an other phone number and authenticate using that? – No, if the system is built properly. That is, the user supplies the phone number at the registration phase (which is supposed to be done in a safe environment) and it can later be changed only after logging in. If there is no safe environment when the user registers for the first time with the website, all bets are off anyway.

But phone numbers can be spoofed! – Yes, but to fool this system, the attacker would have to be able to (a) know the phone number where the call will be placed and (b) compromise the (cell) phone network to re-route calls. While both of these are possible, they are (hopefully) much more difficult than installing a trojan on the users machine

Isn’t it a privacy concern that my phone number is stored in a database? – Yes it is, but if the database gets compromised, there are probably more valuable information than your phone number. Unfortunately it’s not possible to store your phone number as a one-way hash, because (a) the system needs to able to call it and (b) phone numbers are relatively short (10 numeric characters), so a brute-force is very feasible. This can be mitigated if PhoneFactor would offer a service to store the phone numbers, which could work as follows (I don’t know if they have such a system):

  • When a new user register, the site asks PhoneFactor for a UID (Unique Identifier) to be associated with that user
  • The user gives her phone number to the site, which in turn forwards it to PhoneFactor together with the UID and doesn’t store it.
  • From here on, the website only needs to send the UID whenever it wants to ask PhoneFactor to verify the user, and it will know which number to call
  • When the user wants to change her phone number, the website would send the UID and the new phone number to be associated with it, without actually storing the phone number

In this case the information would be split up between two places (the website and PhoneFactor) and unless both are compromised, the complete identity-phone number can not be reconstructed.

What if I’m at a place where there is no coverage for my phone or I’m unable to use it for other reasons (battery died, etc)? – then you are SOL, pardon my language. But then again, what if you are in a place where there is no internet access? Or no fingerprint reader?

PS. I argue that the RSA-style one-time pad generators also fall in this category because one could say that there is a virtual channel between the RSA-token and the authentication server, through the clock built into both of them and the serial number of the token.

, ,

9 responses to “Two channel authentication”

  1. Was wondering how phone factor would stop a active MITM

    1)User want to login.
    2)attacker does a DNS poison and sends the user request to his server.
    3)He(attacker) then opens a new session with the real auth server.
    4)User is given a fake login page to enter his data.
    5)This is directly forwarded to the attacker server where he just resubmits the data to the real server.
    6)Now user is placed a call by server and asked for permission of authetication as he is loggin real time .
    7)User gives his code (real code to server ) to login
    8)Server gives access to the User as he provided the real data BUT inturn Server is authenticating the bad guy and he had access to allthe user info .

    DO perform this attack attacker need not compromise Users GSM network just has to be automate the user request real time which can be done with a $100 kit available in underground crime.

    mitmwatcher.wordpress.com

  2. Actually, there is a system that that I think is better.

    Gardanto has a product called Nedu that does the same thing but uses text messaging to deliver the one time password.

    There are a few advantages to using text messages, one of which is that it will work much better in low-reception areas. It is sold as service (follows the SaaS model) so you can be using it 10 minutes after you finish reading this.

    http://www.gardanto.com

    (Disclaimer: I am an employee of Gardanto, not just because of the pay 🙂 but because we build some really cool stuff here).

  3. @anonymous #1: Yes, it’s very hard in principle for two-factor systems to prevent the kind of active phishing attack you’re describing here. It’s kind of an infinite regress, though, in that you eventually need a secured platform (TPM?) to really address attacks like these. Regardless, it’s very hard for a web browser with just our basic PKI infrastructure to do a lot about this.

    The banks, on the other hand, may be in the position to do something about this, but it’ll cost them some real money.

    I posted more about this on another blog here: http://blogs.technet.com/rhalbheer/archive/2007/07/13/only-the-easiest-way-is-the-secure-way.aspx

    Regardless, active MITM attacks are still the minority. PhoneFactor adds security in enough dimensions that it’s clearly a win for any IT department, particularly given the price (free!).

    @anonymous 2: Text messages have their drawbacks too, of course: lots of people don’t know how to use them, they tend to be billed differently by cell phone providers, and most of all, they can’t be integrated as easily into existing applications like Windows and RADIUS without significant changes in user experience.

    And regarding the point about reception – there’s a very very narrow window in which text messages work (fast enough to be practical) but voice calls don’t. In practice, we’ve never run into complaints about coverage, and besides, PhoneFactor works with land lines as well, so you can just use your home phone if your cell phone is out of range.

    Text messages clearly have their place, and we can definitely agree that the time has come for using the phone as the second factor. Tokens everywhere are quaking in fear. 🙂

    Thanks for the kind words about PhoneFactor!

    Steve Dispensa
    Chief Technology Officer
    Positive Networks
    (the PhoneFactor people)

  4. on anonymous’s comment:

    1) user (Alice) wants to log in
    2) attacker (Bob) uses (whatever attack) to MITM the request to the destination server.
    3) Bob sends Alice’s auth credentials to destination server
    4) Destination Server prompts user for request
    5) Bob offers the prompt to Alice
    6) Alice enters “transfer $1K to this account”
    7) Bob hijacks the response, changes it to “transfer $2K to my account”
    8) Destination Server holds account transaction
    9) Destination Server passes request to Two-Channel system
    10) Two-Channel system contacts Alice (say, over phone), offers transaction details.
    11) Alice doesn’t confirm, because she doesn’t want Bob to get her $2K.

  5. That is to say, what you’re talking about there isn’t two-channel. All authorization requests are passing through the same channel (the internet). A true two-channel system had two authorization mechanisms, one to open a transaction and one to commit it, and they use different communication networks.

  6. I just hacked my friends Phonefactor last week! How. First I must admit, I got his passowrd, but that’s it and it proves that this is one factor authentication, not two. Think about it. If you can get at a password.. then you are in. Think call forwarding and how you might do that, with and without a password. Hmmm…

  7. PhoneFactor doesn’t prevent MITM attacks per-se, but to attack it successfully you have to MITM two channels, which makes it more difficult.

Leave a Reply

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