PhoneFactor: Free two-factor authentication for everyone!
After months of development and a couple of years of research and planning, I’m thrilled to announce that Positive Networks is readying its new two-factor authentication service, PhoneFactor, for launch this summer.
PhoneFactor is a phone-based two-factor authentication system. It works like this:
- A user enters her normal username and password and logs in
- Immediately, the system places a confirmation phone call to her pre-registered phone number
- The user answers and presses # to confirm the login
You’ll notice that there are a few distinct advantages to this system. Most obviously, users don’t have to carry around Yet Another Device. IT departments don’t have to manage Yet Another Device (mailing them out, RMAing them, doing token synch, yada yada yada). And because it’s just a phone call, it works on literally any TouchTone phone in the world - you don’t need a smartphone, a J2ME environment, or anything of the kind.
One of the biggest advantages of PhoneFactor, however, is that it’s free. From the first day it launches, Positive Networks will be making the PHoneFactor service available for free to everyone. More details are available at www.phonefactor.net, but the basic idea is that Positive is going to sign up to providing the standard PhoneFactor service for free, permanently. If you have a VPN product (including, of course, PositivePRO), or a public-facing web application, or a Citrix server, or virtually any other kind of networked application, you can add PhoneFactor two-factor authentication to it for free. Positive will even pick up the tab for the outbound phone calls, as long as they’re to domestic US phone numbers.
The PhoneFactor service is a legitimate free service, in the mode of GMail or Flickr. We plan on keeping it free permanently. It’s not crippleware, adware, shareware, or any other kind of badware. It’s not a trial, and it’s not time-limited. It’s simply a free service.
Now, we also have to pay to keep the lights on, so we’re planning on selling add-on modules to PhoneFactor that we think will deliver even more value than the standard service. We’re also going to provide our world-class administrative and end-user support services and our advanced integration service for a fee. More about the add-ons can be learned at www.phonefactor.net. It’s my honest belief that the standard PhoneFactor service will provide a lot of value to a great many organizations without the add-ons, and will probably be all that most organizations need. But, if you’re a Fortune 500 company considering an enterprise-wide deployment, some of these modules will probably be of great benefit to you.
You can probably tell I’m pretty excited about this. It’s not every day that you get to go out and solve a real problem with cool new software, and to top it all off, I get what every coder wants: the chance for my software to be widely used and appreciated.
The precise launch date isn’t fixed yet, but I expect to hear fireworks when we release it, if ya know what I mean. 
There is a ton of additional information over at www.phonefactor.net, including a particularly fine white paper by yours truly. You can also sign up for the mailing list to be notified when we release.
May 23rd, 2007 at 12:22 am
I was just wondering what will the plight of me if I have no network coverage of my phone at the place i try to login like in netcafes , or in places when i am out of country ,and how you guys will handle misplaced phones.
Though it crubs MITM attacks but l fails to establish the mutual authentication of the user vaildating hte server and also not the new level of phising attacks on phones like this http://www.f-secure.com/weblog/archives/archive-0
42007.html#00001173
Some questions
1)How can I ensure that the phone call (IVR) I get on my phone is the from the bank ?
2)A mitm attack +combination of the IVR setup can easily bypass the system.
As a average user I dont want to get phone calls from the provider for just simple acts I do which will not effect the security of the system.
If I use it for my VPN I log for lets say 20 times a day from diffrent places then i would not perfer getting 20 calls from bank for confirmation
My 2 cents
MitmWatcher
May 23rd, 2007 at 12:57 am
Lots of good questions here. Let me take your comments in turn.
First, if you’re out of range and you need to auth, the easiest thing to do is to call our 24×7 support line and have your number temporarily changed (after strongly proving your identity, of course, similarly to how you would prove yourself to a bank over the phone). Note, however, that we allow administrators to disallow this option.
We’re also considering a couple of other features to address this issue.
Beyond that, though, there’s the basic reality that phones work most places. Yes, there are counter-examples, but people tend not to have phones that fail to work in places that they frequent. They tend to change mobile providers first.
And, practically speaking, this hasn’t been an issue in our beta testing so far. I’ve been using it myself for months, and I don’t think I’ve ever failed to get authenticated somewhere.
You bring up a good point about phishing attacks and mutual authentication. Obviously, before you give any sensitive information away, you want to make sure you know who you’re talking to. In the standard service, the key sequence to confirm a pending login is not a secret, so authenticating the caller is not terribly important - if it’s not really PhoneFactor, it won’t matter, because the impostor can’t affect you, and you haven’t told him anything important.
On the other hand, once you start adding secrets transmitted from user to PhoneFactor via phone, phishing becomes a serious problem. Our Advanced Authentication module does allow administrators to require that users set a PIN that they provide to the system when it calls, making the service “two-factor plus one.”
To combat phishers, the system allows users to record a quick voice print, just like setting up a voice mail box on a mobile phone. During the first call, users are prompted to repeat a word or a phrase into the phone. From that point on, each time PhoneFactor calls, the user’s message will be played back. Presumably, phishers won’t have this recording, so the user can spot a fake.
This similar to the idea that a lot of banks are implementing at the moment, and I think it provides a reasonably effective added layer of security. At its core, though, phishing is a very hard problem to solve.
That F-secure article is hilarious.
Regarding the MITM issue you raise - I guess I’d argue with your assertion that it’s “easy”. It basically requires an active MITM attack, and mitigates against mass-harvesting of credentials. This is a meaningful improvement in overall system security.
Zulfikar Ramzan from Symantec has a really thoughtful post about the issue on the Symantec Security Response blog here:
http://www.symantec.com/enterprise/security_response/weblog/2007/05/phishing_and_twofactor_authent_1.html
To tackle your last point about multiple calls, that is really an administrative policy decision. If you want every single auth attempt to generate a call to your users, fine, that is possible. If, on the other hand, you want to allow a grace period - say, “don’t call the user again if she just authenticated within the last 30 seconds” - you can.
Grace periods can be useful for things like signing onto a VPN, where you might be mapping a bunch of drives at the same time (domains notwithstanding). It also has applications in areas like dual-authenticaion environments where two different auth domains don’t trust each other, but both “trust” (i.e. use) PhoneFactor.
You can further limit grace periods to requests from the same IP address or netblock. In the end, it’s up to you - you must balance your desire for improved security with your desire for ease of use. I think this is mostly an empirical question - administrators will learn quickly what works for their network, their unique risk profile, and their user base.
I’m going to break some of this answer up and use it in my next few blog posts. Thanks for posting.
May 23rd, 2007 at 10:37 am
Good to see a long answer
In security field vendors are less involved in solving the problems of users and more involved in running away from their responsibility of making the users secure .
Take the case of Windows Vistaa the User Account Control(http://blogs.zdnet.com/security/?p=29) flaw instead of OS deciding the which is best for a lame user like me Vista Security designer gave it to the hands of USER saying its not our headache .
I see same analogy of your administrative policy which is asking admin to take all the headache;).
I am not talking of phone network that dont work ,I was mentioning that If i am traveling to different state/country the network found in one state /country cant be found where this I am helpless;(
A hacker will always attack the system at the weakest link I see a weak link in the admin policy,as users will always crib for as you increase the level of security .I think this will explain http://hhi.corecom.com/arc20061001.htm#BlogID558
Some more .5 cents
MitmWatcher
May 23rd, 2007 at 12:51 pm
Interesting point about responsibility shifting. Certainly that’s worth worrying about. Regarding our admin policy, this is one of those cases where a secure default will get you what you want. Administrators never have to know the policy is there unless they hit a usability issue.
Regarding the UAC stuff - there’s a lot of architectural water under the bridge there, and I there’s more to it than just letting the user decide what to do with his box. On a related point, Ken Johnson, another Positive Networks coder, posted about protected processes and DRM recently on his blog. It hits some of the same security-architectural considerations: http://www.nynaeve.net/?p=124
Regarding traveling: if it’s a place you travel to often and/or on business, odds are great that you’ll have a phone that works there. As long as you can roam and receive calls, your PhoneFactor auth will still work, even if you’re standing in the middle of Australia. If you have a CDMA phone, it won’t work in Europe, but most of the world does have GSM coverage at this point.
Regarding the lather-rinse-repeat cycle - I’m not sure I understand what weak link you’re pointing out. I think that’s a good description of a real security problem, though. Maybe you could clarify?
May 23rd, 2007 at 2:26 pm
Good to see the reply .The weakest link I was pointing was the users adaptability to the admin policy.
Anyways thanks for listening and Best of luck for the product
MitmWatcher