So the point was that two factors may not be required (security for security's sake is a waste of resource). But let's go with the cellphone thing for a minute. I'm assuming you'd use it to send some sort of OTP to the user.
Imagine the route that token takes - from your server across the internet to an SMS service (a channel you might secure using TLS/SSL).
From there to any one of an arbitrary number of network operators, again over the public internet. You've no control over this leg. From there the token travels through the network operator's network, to a switch, and then over the GSM network to the handset.
There are at least two places there where you can launch a man in the middle attack.
Which brings me back to the threat model - understanding the value of the asset you're protecting will tell you whether the cost [1] of such an authentication scheme is worth it. Oh, and the cellphone-based OTP is of course an additional asset this authentication scheme introduces.
[1] Cost is not just the cost/per SMS. It's also the cost of developing/aquiring the technology, and then maintaining it and the infrastructure that supports it.
Nope, the solution I posted doesn't use SMS - in fact, it's completely offline. You could have the phone in airplane mode.
It essentially generates a code based on a pre-shared secret and the current time.
As for the costs, as I said there's plenty of free client applications (Google Authenticator is just the most well known), and not only there are plenty of libraries that you can use on your server, as the RFC that details TOTP provides an implementation in less than 50 short lines of code (+ Java boilerplate); see http://tools.ietf.org/html/rfc6238
And you just need that, plus an extra field in your data store for each user (to store the secret) and a textbox in the login page.
I've not come across that one before, and... it looks really interesting. I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time.
Using a phone is a great solution. Except when the app that requires TOTP authN is also on the phone. That's a shame.
Either way, thanks for positing the link, and clarifying. I learnt something today.
I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time.
Well, it uses a 30 second window, so it can cope with small drifts; as long as the phone's RTC isn't broken, you should rarely need to re-sync.
I use it with a J2ME application on a Nokia S60 without an internet plan and it works fine.
Imagine the route that token takes - from your server across the internet to an SMS service (a channel you might secure using TLS/SSL).
From there to any one of an arbitrary number of network operators, again over the public internet. You've no control over this leg. From there the token travels through the network operator's network, to a switch, and then over the GSM network to the handset.
There are at least two places there where you can launch a man in the middle attack.
Which brings me back to the threat model - understanding the value of the asset you're protecting will tell you whether the cost [1] of such an authentication scheme is worth it. Oh, and the cellphone-based OTP is of course an additional asset this authentication scheme introduces.
[1] Cost is not just the cost/per SMS. It's also the cost of developing/aquiring the technology, and then maintaining it and the infrastructure that supports it.