[Cryptography] client certificates ... as opposed to password hashing

Tony Arcieri bascule at gmail.com
Tue May 27 01:54:32 EDT 2014


On Mon, May 26, 2014 at 4:14 PM, John Denker <jsd at av8n.com> wrote:

>  I'm not talking about the existing client certificates,
>  which are a horror show:
>
> http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
>  I'm talking about how it could be done, how it should be done.


You might want to look deeper into existing client certificates:

- The <keygen> facilitates easy key generation within a browser
- The public key (CSR) is then sent to the server to be signed, then the
signed key is sent to the browser for installation
- This certificate is then (optionally) used in subsequent requests

That's great... so what's the problem? User experience

Client certificate UX is terrible in all browsers. Worse, it's inconsistent
between browsers. Managing certificates is terrible. Hell, browsers can't
even decide whether or not they should use the system trust store or their
own.

You can claim that the implementation of client certificates is bad. Fine,
I think your scheme (which seems a bit handwavy in the details) looks worse
than what we have today. But that's all moot. The real problem isn't the
implementation, but UX.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140526/5415e58d/attachment.html>


More information about the cryptography mailing list