Why aren't digital signatures the standard way to authenticate web clients?

Question

The web is a mess of incompatible cookie schemes, asinine requirements ("your password must contain letters, numbers, and at least one symbol from !()-_., and must begin with a letter, and once you change it you can't reuse it"), and unreliable (not to mention centralized) third-party authentication protocols.

It seems to me that the web would be more secure and standardized if public keys were universally treated as online identities the way email addresses currently are. Authenticating a piece of information would be as simple as signing it cryptographically. It could even happen on the application layer, e.g. with an HTTP header Signature: algorithm=sha256;encoding=base64;signed-digest=...;public-key=...

Is public key cryptography truly unfit to serve universal identification and authentication on all internet layers? Or is non-cryptographic authentication a market failure?

Answer 1

The simplest answer is that key/certificate distribution is a difficult and expensive problem.

For certificates to work securely, you generally need some trusted authorities (typically CAs) to sign the certificates. Who would do this? You can't expect some trusted entity to go around and approve every internet user's certificate. You could use a web of trust, but this has it's own complications (Which signatures do we trust? Will casual internet users care about endorsing other people's certificates? Is it even secure to let them do so?). What about certificate revocation? How could you handle that nicely with millions of clients?

Answer 2

You are quick to point out the defects of passwords — and you're right. But no other method has all the advantages of passwords, so any replacement method comes with benefits and costs.

On this topic, I recommend the work by the security group at Cambridge. You may be interested in the authentication tag on their blog. A recent paper on the topic is The quest to replace passwords: a framework for comparative evaluation of Web authentication schemes) summarized in this blog post.

Unfortunately, the paper does not analyze the scheme you propose, with private keys stored on the user's PC and public keys provided by the user at enrollment time as part of their identity. But we can look at the criteria used in the paper and see which ones fail.

• Scalable-for-Users: that depends whether you expect users to have a single identity or one per service.
• Nothing-to-Carry: as long as you accept that the private keys will be stored in a mobile phone, your scheme has the Quasi-Nothing-to-Carry property.
• Easy-Recovery-from-Loss: ok as long as the private key is used for authentication exclusively — changing the private key is as easy as a password reset. (The authors do not consider password resets within the scope of their study.)
• Server-Compatible: no, like just about any other alternative to passwords, servers must be modified. This is admittedly more of a marketing than a technical issue.
• Browser-Compatible: this would depend on how the private key is used on the client (this has implications on security).
• Resilient-to-Theft: passwords are not very resilient, but memorized passwords are resilient to theft, unlike a key stored on a device.

The two major hurdles I see are the risk of device theft and management of multiple identities. Device theft can be countered to some extent by protecting the private key with a password, but the key file is subject to unlimited high-speed brute force search by the attacker, unlike passwords used for online authentication which can be throttled.

Management of multiple identities is a bigger problem: it means the user must decide whether to use the same identity on multiple sites or not. Reusing the same key is convenient but trivially discoverable so it is a major privacy concern. While it is a bad idea for security, users can (and do) reuse passwords with no privacy implication. Using different identities on different sites requires cumbersome management of multiple keys, which is more burden than typical users want. A better scheme would combine the private keys with some repository of secrets, which shares all the difficulties with password managers.

Answer 3

Federated Identity is the name of the problem you describe.

A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.

The reason it hasn't happened on the web is that the web wasn't designed for it from the ground up, and it's a really hard problem to solve. The path of least resistance for most web-sites has been to manage their own password DB.

To understand the problems, consider that

1. Users want to be able to move from one device to another, but there aren't easy hardware solutions for moving key-stores securely from one device to another.
2. A single identity isn't obviously more robust against malware -- it may just become a single point of failure. If malware gets onto one machine, and steals a single private key for the whole web (or a large portion thereof), then you're in trouble. Malware can steal passwords by key-logging, but only for those sites you visit while it persists.

Answer 4

It boils down to economics.

Password security isn't perfect. But it is good enough for most problems in the online world. It also happens to be simple enough for most people to grasp -- even if they oftentimes forget the password itself. Password security also happens to be implementable on just about any platform and user interface you can think of. Oftentimes it is so commonplace as to be baked into your toolkit already.

Certificate style security is nightmarishly expensive to stand up, as Oleksi points out. And you would also have challenges with getting people to be able to use it. Especially in a multi-device world like today. Imagine the fun of helping your mother install her certificate on her smart car.