3 ms·

Part of the problem with this approach is that it uses one single system to represent a number of claims about the client that should actually be treated separa

by 7952 11y ago

Part of the problem with this approach is that it uses one single system to represent a number of claims about the client that should actually be treated separately. Identifying a user (who has history on a site) is different from identifying a hardware device, or a particular browser instance. Without knowing which particular claim the certificate is presenting it is hard to know how much to trust it. Just building a GUI does not solve this problem, and usage could create a false sense of security. If a machine is compromised is a client cert really any better than a cookie?

jdmichal 11y ago
> If a machine is compromised is a client cert really any better than a cookie? I'd say that currently, it's actually worse. At least a cookie can be easily invalidated and regenerated, and typically expires after a relatively short time. Invalidating a cert is easy enough from the server side -- just stop accepting it. But how do you invalidate it and regenerate a new one on the client side? Well, currently, you ask the user to go into scary menus and do scary operations to delete the existing one. Then you can request the browser to generate a new one. I think this is exactly the heart of the question that the article is asking. How do we make certificates a better form of authentication cookies?