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

Steve Weis steveweis at gmail.com
Tue May 27 17:48:05 EDT 2014


On Mon, May 26, 2014 at 10:54 PM, Tony Arcieri <bascule at gmail.com> wrote:
>
> 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.
>

Just as an anecdote, MIT has been using client certificates to
authorize access to web pages since the 90s:
http://ist.mit.edu/certificates

They either officially or unofficially support most major browsers and
platforms. The exceptions I see are Opera, Windows Phones, and
Blackberry.

Incidentally, I ran across MIT's web single sign-on system called
Touchstone, which apparently can support federated certificate-based
logins from other organizations: http://ist.mit.edu/touchstone

In general, initial setup per device for client-side certs is still a
pain, as is maintaining support across many different platforms and
browsers. That's why I think client-side certificates have really only
worked for organizations with closed sets of users and full-time
support staffs.

However, for mobile apps, client-side certs might work well if they
were generated upon installation, without any user interaction. For
example, Twitter's app is generating a client-side keypair for login
verification, which is somewhat acting like a client-side certificate:
https://blog.twitter.com/2013/login-verification-on-twitter-for-iphone-and-android


More information about the cryptography mailing list