No, if they were then you wouldn't have to type extra numbers into your browser.
That seems kind of like a 'nit', I know, but if we learned anything from Steve Jobs it is that there is a difference between providing an answer and providing a solution.
The elements that will be present in a solution include;
1) You won't have to type anything else, a program will have an API which can definitively tell it you are making this request or you are not.
2) The 'key' won't be anything else, it won't be an app on your phone or a plug-in to your browser.
3) It will work with any service you care to use it with and if it has not been implemented there will be no legal/enumberance/techincal barriers to doing so.
4) It will not degrade your privacy options.
Google's two factor authentication fails on a number of these, not the least of which that it requires that you own a 'smart phone' which is something my father in law will never do before he dies.
As I said elsewhere in this thread, some countries in Europe require you to use a fob that generates another key for your second authorization factor. But you still have to type in extra numbers. How would you get around that? How does the service know that you're in possession of the key unless you give it some kind of input about the key that's unique to the key and to the current time?
Personally, I much prefer having it on my smartphone, and this seems like a good approach considering smartphone adoption rate. But Google's 2-factor will sms your dumb phone, too.
How does the service know that you're in possession of the key unless you give it some kind of input about the key that's unique to the key and to the current time?
Lets say you've got a 'fob' which is plugged into a USB port. Application sends the fob a challenge, fob responds. Application validates the response and proceeds. Perhaps the key uses 2.4mhz wireless, perhaps it uses bluetooh (a protocoled 2.4mhz wireless solution :-). The benefit is that these things can only occur when you're key is present. No key, no transaction.
We don't worry about Nigerians stealing our cars, but we should consider what they might do with our self-driving cars if we don't have some durable way to say we're in the car right now.
I appreciate that you prefer having something like this on your smart phone, but such a solution fails for the larger internet population. And while SMS works for 'dumb' phones you cannot have it validate on every send, every post, every tweet, every page view.
You may not share my urgency on this as a threat but I invite you to start to watch more closely. In the Atlantic article a Google representative said "Thousands per day" this is big business for folks. I was talking with a senior executive at Wells Fargo who mentioned hundreds of millions of dollars 'lost' every year. This is a growing problem, its getting more expensive, and like some digital herpes my expectation is that it is going to pop out suddenly in boils of financial putritude dripping pain, financial suffering, and expense for everyone involved. With luck we'll fix it before then but most folks who are getting burned are more interested in covering it up rather than addressing it sadly.
I think it would be wonderful to have a possible solution prototyped and demonstrable for people in pain. Your passwords will be compromised, and if you do anything financial online you will have money vanish and you will experience arguing with a bank as to why they should give it back to you and take the loss. This isn't a 1 in 10, or 3 out of 5 type statistic, I'm pretty confident that every single person who has an online account which can tranfer funds (whether its an iTunes account or a checking account) will experience this. 100%.
> Lets say you've got a 'fob' which is plugged into a USB port
I still fail to see how this solves anything. Once you get malware on your computer, that malware can send requests to the USB device, and you're back at square one.
One of the features of RSA security fobs is that only someone physically present can use it. What you've made is an RSA fob that's vulnerable to viruses.
The protocol between the service and the FOB allows for any program sitting on the computer to snoop the entire exchange and be unable to reproduce it. The simplest example of this was the Millicent protocol which used an MD5 running backwards as a one time pad, although that had other issues.
But lets say that at the 'introduction' stage the service set a cookie with the fob by saying 'remember this about me, I'll call my self ecb994af and your magic number is 3551eff' then later on verification passes it sends a message encrypted by its self key to 'tell me your magic number divided by 2 and encrypted with your id.' The attacker can see the whole sequence but if they don't understand what is being asked and returned they can't reproduce it, and they don't have the initial secrets either.
There are lots of ways to do this with smart protocols. Something I tried (and failed) to patent back in the Java days where you sent a packet which could be executed. The nice thing about such protocols is they can be dynamically designed between device and service and malware is stuck out in the cold.
There are things it cannot protect against, malware running in the Google servers or Amazon's for that matter which has access to all of their server data. But if it does get compromised it only compromises one relationship, no additional damage is done because other systems can have their own protocols, their own dynamic data.
For this to work, you'd need a trusted connection between the fob and the server. So this reduces down to relying on a CA system, which first of all isn't open, and second we now know works very poorly. Heck and on the USB device you wouldn't even have a secure way to able to update the CA store to remove bad actors.
The problem I see with this solution is that it would require a plugin to be installed on your browser in order for the browser to have access to the fob. This alone is enough to discourage a lot of people from using it.
Also, you wouldn't be able to log into a public terminal.
In the ideal world, the spec would be open and anyone could implement it in their service (be it a browser or other). For most operating systems we're talking about something that looks like a device connected over a serial port. The Android service is pretty straight forward and I've played a bit with ideas on an old G1 which had a serial port hidden in the USB port, not sure about iOS. Computers like laptops etc its very straight forward (for both wireless and wired solutions).
"Also, you wouldn't be able to log into a public terminal."
Actually depending on capability (no pun intended) I could easily see 'read' access being usable without the key but recognize the issue there. The real 'issue' if you will is universal appeal/buy-in which is to say if anyone can use it then you will get some early adopters who will provide support as a differentiating factor and that can drive adoption into more slowly changing markets. Because it has to be everywhere to be effective it won't be a big money maker (this is where a lot of VCs stop listening :-) basically the barrier to implementing it has to be 0 and the value to the implementor has to be non-zero. Given how thinly marginallize 'security' fixes are, this margin won't leave anything for the manufacturer in terms of on going revenue so the key itself has to define the value for the company. (I've actually thought a lot about this :-)
So to your point, for early adopters the experience would be to get a 'key' and to install a plug-in and then enabled sites and services would be secured. Pretty easy sell to an enterprise if their only cost is the 'fob cost' and there isn't some giant consulting revenue stream attached to it. For big companies it has to be completely implementable (once the key infrastructure is set up) in a way that is custom (and probably private) that enterprise. That gives their IT folks confidence and it makes the risk low.
For more general engagements like PayPal or Facebook its a bit different. On things that are appifyable (if that makes sense) there is a potential for differentiation (look at how the World of Warcraft Authenticator stuff was worth it for them to implement).
The key for me is that the existing way of doing things is under attack and it will eventually succumb, when it does there is a tremendous opportunity there.
Using a TPM to ensure that only trusted software is accessing the fob as well. We're still a little ways off from a completely cryptographically secure software stack.
less of a nit - if your browser automatically confirms your identity, whatever token it's based on, the privacy implications may not be completely warm and fuzzy
Separate them in time. If the protocol is well documented and there are free source code implementations available then that removes the barriers to implementing it in new systems, and plug-ins or some other form would be needed for older systems but the plug-in itself could be implemented by a third party rather than have to come from the key manufacturer because of the open spec.
That seems kind of like a 'nit', I know, but if we learned anything from Steve Jobs it is that there is a difference between providing an answer and providing a solution.
The elements that will be present in a solution include;
1) You won't have to type anything else, a program will have an API which can definitively tell it you are making this request or you are not.
2) The 'key' won't be anything else, it won't be an app on your phone or a plug-in to your browser.
3) It will work with any service you care to use it with and if it has not been implemented there will be no legal/enumberance/techincal barriers to doing so.
4) It will not degrade your privacy options.
Google's two factor authentication fails on a number of these, not the least of which that it requires that you own a 'smart phone' which is something my father in law will never do before he dies.
So no, Google doesn't do this yet.