Skip to main content

PhoneFactor Security

I was asked recently to look at the security of the PhoneFactor 2-factor authentication solution. If you don't know what it is, then you can find out more here, but essentially you enter your username and password, then they phone you on your pre-defined number and press the # key to validate the authentication. The problem with just pressing the # key is obvious, but they allow you to configure entering a PIN number rather than just pressing the # key. To my mind, there should be no other option than having to type in the PIN number. However, this isn't necessarily a brilliant idea. As I've said before in this blog, a lot of phones log the digits dialled, in which case that PIN isn't secure.

I was also told that the PSTN and GSM networks are secure, so this is a good solution. I'm not sure I agree that PSTN and GSM networks have good security. Analogue PSTN is easy to listen in to with proximity and GSM can theoretically be cracked, and probably will be within 6 to 12 months. So that PIN number isn't really secure. Plus there is the cloned SIM card problem as well.
http://www.mobileindustryreview.com/2009/08/gsm-encryption-can-be-cracked-for-500.html
Having said that, PhoneFactor looks quite good as you enter the PIN on the phone line, not the login dialogue. The problem that Bruce Schneier has referred to is that of a Man-in-the-Middle attack. Most 2-factor authentication methods are susceptible to a MITM attack, including RSA tokens and other hardware tokens. Basically, if I set up a website, for example, to mimic your corporate portal, then you will enter all your details into my page, including your one-time pass code. I will forward them on to the real portal and do whatever I like logged in as you.

The one advantage is that I have to intercept every login attempt, and wait for you to login before I can gain access. Without a 2-factor system, once I've read your username/password combination I can login whenever I like. PhoneFactor would appear to mitigate some of this risk by doing the authentication out of band. However, there is still an attack vector for a MITM attack. In the same way as before, you login to my portal, I forward your credentials, PhoneFactor phone you and you put in your PIN, they enable my session! Obviously, there are other attack vectors as well.

Another potential issue is that you are charged for the phone calls made by PhoneFactor on your behalf. These can be significant costs. In the UK calls to landlines are free, but am I always at my desk when I want to log in? No, I'd want it on my mobile; that will cost me $0.23 per login (East Timor $3.25). So, I could rack up the bill for you company by getting them to call through to someone. If I do this enough times (especially if that person is on holiday in another country with higher charges) I can use up all your credit and none of your users can login.

There is a privacy issue as well. PhoneFactor will know every time you log in or access your bank, etc. How do they protect that data? Do you want them to know that information, even if you do trust they won't accidentally disclose it?

However, I am not against 2-factor authentication. Indeed I think it is a good thing, as users will choose poor passwords, reuse them everywhere and write them down. Similarly, they will give them away to phishing scams. 2-factor authentication removes all of those problems, but by no means is it absolutely secure. PhoneFactor seems OK, but it's not particularly cheap or phenomenally secure. There are some other good software solutions that are pretty cheap as well, and that can combat shoulder-surfing when entering PIN numbers, etc. There are a couple of examples on a blog post I did a couple of months ago: http://blog.rlr-uk.com/2009/06/user-friendly-multi-factor.html

The bottom line is that they are more secure than username/password, but none of them are absolutely secure against all attacks.

Comments

  1. PhoneFactor now allows voice authentication.
    This is a bit higher maintenance, but probably more secure.

    ReplyDelete

Post a comment

Popular Posts

You say it's 'Security Best Practice' - prove it!

Over the last few weeks I have had many conversations and even attended presentations where people talk about 'Security Best Practices' and how we should all follow them. However, 'Best Practice' is just another way of saying 'What everyone else does!' OK, so if everyone else does it and it's the right thing to do, you should be able to prove it. The trouble is that nobody ever measures best practice - why would you? If everyone's doing it, it must be right. Well, I don't agree with this sentiment. Don't get me wrong, many of the so-called best practices are good for most organisations, but blindly following them without thought for your specific business could cause as many problems as you solve. I see best practice like buying an off-the-peg suit - it will fit most people acceptably well if they are a fairly 'normal' size and shape. However, it will never fit as well as a tailored suit and isn't an option for those of us who are o

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform