Jim, I consider your insights to be some of the best , but with multi-factor authentication, what you have, what you know, etc. I might still have some issues with someone who says whom he or she is on the phone just because they say so or even using a third factor of the origin of the call which also can be compromised. Still I again try to catch your contributions because they are always excellent in my opinion.

Hi Steve, might be a little confusion as to how this works. First, the calls only come when you as a company have set up to use PhoneFactor with one of your internal systems. Second, the call only initiates after someone has successfully logged into using the first factor (user name and password). Third, the call is automated (not a person) and will only come immediately upon logging into a system (not just out of the blue). Finally, there's no benefit to spoofing the call.

(Sorry the post is so long, but the topic is interesting.)

Sounds interesting, and for the corporate client very cost-effective (free!).

But the business model doesn't sound right. Since PhoneFactor is making an automated call to a phone number (which is more likely than not to be a cell phone - there are easier ways to confirm deskbound users), then somebody has to pay for the call - which could be anywhere within the country. Lots of people = lots of calls, and even with a great service plan, those bills will mount up rapidly for PhoneFactor. It gets worse since there are the issues of scalability to call thousands of users concurently. Yes, one can use VoIP systems at the PhoneFactor end, but the carrier which will convert those IP calls to traditional phone lines will hopefully be able to scale seamlessly.

Also, it almost has to be a cell phone, as you need to have a true one phone number to one user account relationship. Otherwise, a miscreant could answer on behalf of the real user. While most large corporates have dedicated numbers and direct inward dialling (or PBX-based auto attendant features which automatically forward dialled extensions) for their users, small businesses and some branch offices rely on shared access to phone lines, or some form of human or automated attendant which wouldn't transparently support the transfer.

Regardless, the model doesn't really seem financially sustainable in the long run, as the value-adds aren't high-priced or mass market heavily demanded options.

Having listed the above, I also see a couple of other issues from the end-user point of view. First, if my cell phone has weak coverage in the geographic area I'm logging in from, then the call might not get through. So I can't log-in. Yes, I can try to get homebase to either allow me to by-pass the access or reset to another number - but that "human intervention" increases the cost to the corporation, as well as delays my getting access. Second, if many users all want to log-in at about the same time of day, I can just imagine the congestion, and thus subsequent delay, as I wait for my log-in to authenticate at 9:00 am each morning.

I should head over to PhoneFactor's Web site to see if they have addressed such concerns.

However, if I were them, I would take the concept one step further, and permit the option of the call being sent to one of a text messge being sent, to which the end-user responds with a basic code (i.e., three letter code). Using text messaging is advantageous in that it can often get through when signal coverage doesn't support voice calls. It can also scale a lot faster for a lot less money than with voice. Congestion is less likely. The whole system can also be automated. I don't know what percentage of PhoneFactor's targeted market has text messaging support on their phones, but I'd believe it is quite high. As I'm based in Nigeria, I don't know what the costs to support text replies would be, but I'd imagine that (as happens here in Nigeria - a backwater of mobile telephony) deals could be done with the service provider to slash the costs of the responses, if the end-user was leery of using his own plan-associated free text message allocations.

Someone I'm sure will highlight that responses with a hash tone are far faster than the speed of a return SMS, but I would challenge that if there is any delay (depends on how soon into the calling message you can send the hash tone), that it is a minimal annoyance compared to having to endure some cringe-inducing voice over and over each day (just like in "Groundhog Day").

If PhoneFactor does want to uses text messaging as part of their solution, maybe I can work out some payments for licensing the patent on the concept...maybe a free annual trip to Disneyland for my family...from here (Nigeria)..by First Class, of course.. ;=)

Apart from the hassles, most corporates, could easily offer the same type of PhoneFactor authentication services from in-house resources (especially if the calls were across their existing voice WAN links). As such, this opportunity is more attractive to SMBs with numerous mobile users.

Finally, its a good idea but needs to be refined beyond a dot-com approach. And one needs to CHARGE the corporates up front - even if it is a minimal amount to cover call (or messaging) costs. Corporates would agree because there is value in doing so.

P.S. Hi, Jim. I've been reading your stuff from God knows how long. Probably early '90s in PC Week. Keep it up.

Hi all,

My name is Steve Dispensa, and I'm the CTO of Positive Networks and an architect of PhoneFactor. Let me try to respond to some of the questions here.

First, as far as the business model goes, yes, someone is paying for the call. It's just like LogMeIn.com paying for the bandwidth to their data center, or Google paying for disk space for GMail - it's inexpensive enough in some cases (e.g. US domestic calls, western European calls, etc.) that we feel comfortable giving the service away and picking up the phone bills ourselves. Barring a major change for the worse in phone call rates (unlikely), we're committed to keeping the free service free for good.

There are phone numbers that are NOT cheap to call, however, and we're rolling out a program (today!) to allow people to pick up calling costs to those numbers. We're passing through our own telco charges to end users, so the rates will be very competitive, but in the end, it's totally up to the IT department as to whether this solution makes sense for them. I suspect it will in some cases and may not in others.

It doesn't strictly *have* to be a cell phone, either. We have cases where permanent remote workers want to work from home, where they have a land line but poor cell coverage. Their land line is set up to ring. Everything works fine. The second factor is still meaningful; it's just that it also implies the user's location, which cell phones do not. Again, not a super common scenario, but it does exist.

Regarding the value-added components: we have targeted the value-added features of the service, above and beyond the basic, free product, at the enterprise market. Enterprises have specific, sophisticated needs that most small- and medium-size businesses don't have. We've had a good response from that market already, and there's a lot more that we will be doing in the coming months. PhoneFactor 1.1 has a ton of additional enterprise-level support, as well, which is due out in October.

Regarding the dead cell phone question, there are a couple of things to keep in mind. First, users don't often work on the Internet in places that they don't have cell coverage. The exception cases are often easy enough to handle with a land line, as I described above. Still, if a user loses her phone or something, she *will* end up having to call in to support to strongly authenticate herself.

On the other hand, you have to consider how likely it is for a user to actually lose or break her phone. Unlike an RSA token (for example), users place a lot of primary value on their phones. They're rarely without them, particularly when working, and they're already a part of their daily routines. RSA tokens get lost or broken often enough that it presents a serious problem for the IT department, and one that requires human action - mailing a token, etc. - so other hardware-based solutions have serious costs built into the broken-hardware case. (By the way, we're readying an enterprise add-on to allow users to strongly authenticate themselves and pick a new phone number; we plan to roll it out to enterprise customers in 2008.)

Regarding SMS pins - there are some integration and usability issues there too. For example, to really use them securely, you wind up having to modify applications to ask for PIN numbers instead of just passwords. You have to add an authentication phase to the application to kick off sending of the PIN. Or, you have to trigger sending of a PIN by some out-of-band method. It's not impossible, and more power to you if you want to do it, but to truly scale two-factor to a large audience, including people like my mom who would *never* figure out how to use text messaging, you're going to need something easier to manage.

One parting shot - Positive Networks has been providing managed security services since 2001, and one of the things we do is provide best-in-class end-user support. If a user runs into a problem, be that a phone problem or a usability problem or anything else, they can call into support and a Genuine Human Being will answer the phone and provide help. Our support is available with everything we sell, and IT departments love it.

Here it is, about 9 months later. Has anyone among you actually implemented PhoneFactor at this point? I'd love to hear how it has worked out. Especially regarding thin client setups like terminal services

We've tried the free version works well, easy to set up, easy to manage

ARe there any elements of the phonefactor service you think that distinguish it from other 2-factor solutions?

Yup, I'd focus on hardware management and ease of use. Hardware management is completely off-loaded to users, i.e., their own phone. Ease of use because all they have to do is wait for a telephone call and dial "#".

Cost should also be a strong consideration. Phonefactor is free to try from product POV, but also cheap in terms of experimentation. Took us 30 minutes to load it to terminal server and see whether it was right for us. Phonefactor picks up cost of outbound calls. Also don't misunderestimate ;-) the soft costs of managing tokens in the field, mainly in terms of time helping users figure out what to do next.

Other big point with phonefactor is the "Out of Band" consideration. Most 2 factor focuses on using the same network connection for both the "what you know" and "what you have." In fact, when you think about the typical "what you have," you actually translate it into a "what you know" and type it into the PC. This feeds right into the hands of phishers and malware. Using a completely separate network for input and output makes it really hard for someone to piece together the information required to get access to restricted content.

They actually cover the cost of the outbound phonecall.

How about fraud notification? Is there a good way that phonefactor manages this? I'm interested in using it for OWA Authentication.

Pretty interesting and elegant solution here: If a user receives a call from PhoneFactor and the user was not logging in to her account, then she knows immediately that an unauthorized user is trying to access the account. The user selects the "*" button on the phone to communicate that she has not attempted to access the account. This essentially communicates that the username and password have been compromised.

Big surprise for me using PhoneFactor for OWA Authentication is how supportive our user community has been. Unlike most measures we've taken to enhance security, users have been relatively enthusiastic about this. They know it is for their own good and the burden to adopt is pretty natural and easy for them.

Has anyone used PhoneFactor with Logmein? My boss tells me using a remote desktop isn't secure because you use just a username and password. I noticed PhoneFactor is compatible with LogMeIn and need some reference to give to my boss if PhoneFactor is a good solution with LogMeIN.

Thanks

Pansy G

Firstly thank you to Steve Dispensa for the comment above articulating the ethos and methodology behind PhoneFactor, very interesting and informative.

In response to Pansy on Aug 30th comment, I've used PhoneFactor to increase my LogMeIn security in my business and it's been fantastic. Easy to install and easy to use. And for the many of the reasons Steve gave in the above comment we haven't really had any issues.

Tell your Boss he won't go wrong with selecting PhoneFactor for 2-factor authentication.

I just came across this post...Would have been great if I had got this a year ago when you posted it. Someone recently hacked into my computer:(

Just tried downloading Phonefactor for logmein. Worked great and had no trouble. Phonefactor definitely solves the second level of authentication issue for free for my computer.

Thanks!!

For anyone interested there are normally three categories for authentication:

1) Who
2) Have
3) Know

Who, is biometrics e.g. retina scan, and expensive to implement and intergrate
Know, is what you know e.g. username and password, and can be mismanged
Have, is things you have on you, the most ubiquitous item cell phone.

Phonefactor has is currently trying to screw all of their small and medium sized customers. Their pricing is rediculous, and their models dont make much sense. If you are using the free version you now have to find another solution quick or fork over $12,000/yr up front, no month to month if you have more than 25 users and need more than x# of auth request per year. Run away from this shady company, it looks like they are cleaning out thier customer base before closing shop.