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

John Denker jsd at av8n.com
Mon May 26 19:14:49 EDT 2014


Imagine a far-away culture where there is a recent fad 
that involves putting lipstick on pigs.  This is a hard 
thing to do.  Lots of things can go wrong.  

More recently, somebody decided to have a contest to find 
the absolutely optimal way of doing it.  A bunch of smart
people took it as a challenge.  They discussed it at great 
length.  They even organized a pig-makeup /contest/ to see 
who was the smartest of them all.

Then one day one of the children asked, why are you trying
so hard to optimize something that you shouldn't be doing
at all?

=============

Ideally, there are several properties we would like a
password (and the surrounding system) to have:
  a) Easy to remember over long times.
  b) Easy to type in.
  c) Sufficient entropy content.
  d) Not shared between sites.
  e) Resistant to passive eavesdropping.
  f) Resistant to active MITM attacks.
  g) Resistant to catastrophe, such as when Target or
   eBay loses a huge database.

The problem is, (a) and (b) conflict with (c) and (d).
This is a problem.  Hashing helps with (g).  SSL helps
with (e) ... but as it is currently deployed, it doesn't 
really resist MITM attacks (f).  In any case, you're 
still stuck with (a), (b), (c), and (d).  You're still 
putting lipstick on a stinking pig.

=========

Right now the "tradition" for doing e-commerce relies
on x.509 certificates to authenticate the server, plus 
login/password to authenticate the client.  It's hard
to decide which end is more problematic.

There are various cases to consider:

1)  Let's quickly deal with a trivial case:
 Suppose I don't control the client machine, for instance 
 when I am visiting an internet café in Lagos.  Then I'm 
 not going to use a password at all.  I'm not going to 
 do anything that requires security, authentication, or 
 authorization of any kind.

 In other words, if you can't secure the endpoint, you
 can't secure the connection.

 Therefore, we now focus attention on the case where I 
 /do/ control the client endpoint.

2) Assuming I do control the machine, I can install a
 password manager.  In fact this is what I've been doing
 for years.

 That means I can use really strong high-entropy passwords.
 I can use a different password for every site.  I don't
 need to remember any of them.  All I need to do is 
 remember the key to the keys, and since I use that often,
 there's no problem.

3) HOWEVER >>>>> None of that really makes sense.  For the
 same amount of work ... actually *LESS* work ... we could
 get a better result using client certificates.

 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.

 It doesn't even need to be fancy.  Suppose the Acme Anvil
 company starts a "secure" session with me.  Rather than
 sending them my ID and password, I send them the following:
  -- My claimed ID, plus
  -- The Diffie-Hellman secret that they sent me,
    signed with my PGP private key.
  -- The first time, I send them my PGP key fingerprint, 
   so they can look up the public key.

Note that I could cut-and-paste this into the "user" and
"password" fields of an existing form, just as easily as 
I cut-and-paste a longish password today.

This is tantamount to a zero-knowledge proof that I hold 
the private key.  The PGP web-of-trust is not required
here.  They have /at least/ as much reason to rely on my
PGP key as they ever had to rely on my password.

Also, suppose security has been lost at /their/ end.  This
could easily happen if there is a MITM attack, using a
forged version of their SSL server certificate.  This is not
the least bit implausible.
  http://www.theregister.co.uk/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/
Any decent client-certificate scheme would instantly detect
this.  The MITM fails unless he can compromise /both/ ends 
in this situation.  This stands in contrast to anything that 
sends passwords over the link, where as soon as the server 
gets compromised, the passwords get stolen.

Let's be clear:  The hassle required for setting up and
operating a password manager is strictly greater than the
hassle required for doing something with certificates.

A password is in some hypothetical sense easier *IF* you
assume you are the first and only e-commerce site in the
world, and you are only doing low-value transactions, and
you are never going to be attacked by anybody with serious
resources.  However, that just doesn't scale.  In the real, 
non-hypothetical world, there are too many e-commerce sites, 
and the dollar volume is large enough to make them attractive 
targets for serious attacks.  Whatever lame excuses there 
were for using passwords 30 years ago, those excuses have 
long since lost any semblance of validity.

My suggestion:  Shut down the password hashing contest.
Take half of the people who would have worked on that, and
have them work on writing a browser plugin to deal with
client certificates in a nice way.  Have the other half
write an Apache plugin to handle the other end.

This is more work than password hashing, but it is entirely
doable.  And unlike password hashing, it accomplishes
something worthwhile.

4) Tangents and creeping features:

 There are issues with syncing the certificate manager if
 there are multiple client machines, but this is manageable.
 It's certainly no worse than having a password manager.
 There are good things you can do with phone+computer, but
 let's not go into that right now.


More information about the cryptography mailing list