On Mon, Sep 30, 2013 at 9:55 AM, Guido Witmond <gu...@witmond.nl> wrote:
> On 09/30/13 17:43, Adam Back wrote: > > Anyway and all that because we are seemingly alergic to using client side > > keys which kill the password problem dead. > > > Hi Adam, > > I wondered about that 'allergy' myself. I have some ideas about that and > I'm curious to learn about other. We use client certs extensively for S2S authentication where I work (Square). As for web browsers, client certs have a ton of problems: 1) UX is *TERRIBLE*. Even if you you tell your browser to use a client cert for a given service, and you go back to that service again, browsers often don't remember and prompt you EVERY TIME to pick which cert to use from a giant list. If you have already authenticated against a service with a given client cert, and that service's public key hasn't changed, there's absolutely no reason to prompt the user every single time to pick the cert from all of the client certs they have installed. 2) HTML <keygen> tag workflow is crap and confusing. It involves instructing users to install the generated cert in their browser, which is weird and unfamiliar to begin with. Then what? There's no way to automatically direct users elsewhere, you have to leave a big list of instructions saying "Please install the cert, then after the cert is installed (how will the user know?) click this link to continue" 3) Key management UX is crap: where are my keys? That varies from browser to browser. Some implement their own certificate stores. Others use the system certificate store. How do I get to my keys? For client certs to replace passwords, browsers need common UI elements that make managing, exporting, and importing keys an easy process. Passwords may be terrible, but they're familiar and people can actually use them to successfully log in. This is not the case for client certs. They're presently way too confusing for the average user to understand. -- Tony Arcieri
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
