This is something that has been thought about in detail - see https://vtllf.org/blog/ssh-web-sign-in/quest-to-replace-pass... for Stajano's analysis.
That said, I think it's bad to rely on one factor. If the key gets stolen, security is compromised. The combination of a password and a security token is far more secure. People should just stop memorizing passwords for every site and e.g. use a password manager.
Sure, but it's super easy to make backups of virtual keys. It's a digital file - just copy it.
Worried one backup isn't enough? Make a million. Space is cheap.
No, I despise passwords. The whole scheme is backwards. I don't want to authenticate myself to the server; I want to authenticate the server to me. Why doesn't it provide the password, and my computer verify it? Why is a fallible human being in this game at all?
Well, yeah. That was a hyperbole. I didn't actually mean that you should go out and make a million copies of your key.
It simply meant to show that it's easier to prevent the loss of a virtual key than it is to prevent the loss of the physical key.
> The whole scheme is backwards. I don't want to authenticate myself to the server; I want to authenticate the server to me.
That's... interesting. My first thought when I read that is that the server is the one with your data and multiple users - so it needs to authenticate you to make sure that you only access your data and don't gain access to other users' data.
A server authenticating itself with you would tell you that you're actually talking to XYZ and not an imposter, but once that authentication took place you'd have access to everything on that server. Including other users' data.
How do you imagine this working?
So we are both authenticated to one another. Except now, we're using sophisticated passwords and Digital Computer Logic to work them out. Instead of my fallible wetware.
And passwords can be stolen remotely using trojan software. You won't even know whether your password was compromized.
I agree the recovery can be a problem but there probably are ways to solve it.
But, sadly, it's not usable. See my reply to grandparent comment.
You can't lose your fingerprint, but you can't replace it either - so what happens when somebody clones it?
It's called TLS client certificates and no one supports those.
Browser vendors make UIs that are absolutely awful (it's like they do this on some damned purpose!), there is no synchronization for low-security software tokens (yup, it's not a big deal to sync some private keys in a same way we sync other credentials like passwords), standardizing organizations don't work on multiple signatures (say, gradually ditching X.509 in favor of OpenPGP - TLS doesn't really care how blobs are encoded). So, the sites don't consume them, although technically everything's there - a <keygen> element, JS APIs, TLS, anything.
On the other side, client certificates (be it TLS with X.509 or whatever) are generally considered as password replacements.
I mean, I suppose many don't want a password - just click an identity with autonomous credentials that don't depend on any third party, optionally do the confirmation ritual (hardware button, PIN entry) - and get recognized.
You can say the same about credit cards: they can easily be lost, stolen etc. But generally they are better protected than internet bank account with just a password.
And the most appealing point is ease of use. Inserting a key and pressing a button is much easier for a common person than dealing with complicated matters like login, email or password.
I've physically lost one credit card and had multiple ones canceled unilaterally by the bank because some idiot merchant got hacked. On the other hand (afaik) I've never lost any bitcoin or any bank logins/passwords that were fully under my control.
http://www.theguardian.com/technology/2015/sep/11/gchq-passw...
It wouldn't be as secure as a special purpose device, but it would be a whole lot more convenient. Given that people are using banking and pay apps on their phones, I think it doesn't really introduce any new issues for the typical user.
But using bank application on a phone is totally unsecure. A modern phone is a computer with complicated software that can be exploited.
Passwords are awful UX design solution. The users have to think of and remember some meaningless phrase to get the service they really needed. If you use easy password, your account can be hacked. If you use difficult password, you won't remember it in a week.
For some people remembering a password or login might be especially difficult.
You can use software to generate and remember passwords but all of them will be lost if you reformat your drive. Some of password managers are proprietary, non cross-platform and some would upload your passwords to the so called cloud so NSA can look at them too.
In any case your passwords can be easily compromised when your PC is infected or you use somebody's else device.
What we need is to get rid of this obsolete system. We need hardware authorisation key (that could look like a real key) that can be used for both registration and logging in and would generate and securely store private keys for all used services. Such device should use strong crypto, should not allow exporting private keys, update firmware or operate without user confirmation.
I think such kind of keys will appear sooner or later, they are superior to passwords and password managers and easy to use but I am not sure that they will be open source, cross platform, and backdoor-free unless we do something in advance.