[Security] TLS Certificates Verification

Dave Cridland dave at cridland.net
Thu Aug 21 03:46:45 CDT 2008

On Thu Aug 21 04:35:16 2008, Justin Karneges wrote:
> On Wednesday 20 August 2008 03:10:54 Dirk Meyer wrote:
> > Maybe it is a stupid idea, but why not use the md5 sum of the key
> > password as server password? Replace md5 with sha256 to be more
> > up-to-date.
> Yes, that's sort of what I was thinking.

IIRC, MD5 would be okay there, although it'd raise some eyebrows. You  
need a preimage attack to get the private key, and (from what I know)  
MD5 and SHA have the same levels of preimage weakness found thus far.

Still, might as well use SHA-512 or something - although someone  
determined could still simply brute force a password in a week or two  
by hiring a botnet.

>   It would probably work for fresh
> accounts.  Unfortunately for users who already have an account, it  
> would be a
> risk to use the same password for their private key.  They'd have  
> to pick a
> new password to bootstrap the system securely.


>   Another issue is that the
> client would need to know in advance that it should send a hashed  
> password to
> login to the server.  Accidentally sending the plain one could  
> result in a
> private key compromise.  We can't rely on a server feature to tell  
> us which
> way to authenticate either, since it is the server we're not  
> trusting! :)  We
> also can't rely on the user always using a proper client.  The  
> moment they
> play with some cool new Jabber client that only supports PLAIN,  
> there they go
> sending their private key password to the server (or worse, over an
> unencrypted link, where *anyone* could get it).
No, it's far worse than that. Most SASL implementations store  
passwords in the clear, especially if they support multiple  
authentication mechanisms.

So merely using DIGEST-MD5 doesn't mean the server doesn't know your  
real password anyway.

> But Remko's right, if we require two passwords (one for Jabber, one  
> for a
> private key) then a lot of people will just make them the same,  
> completely
> defeating the point.  I think we'll have this problem whether or  
> not the
> private keys are stored on the server or locally.

Oh, I think most people will (and possibly even should) keep the  
private key without any specific password. What'll happen in a  
pragmatic-but-reasonable world is that the key will be in the  
operating system's "secure store", just like their password often is  

If they have to put a password on it, it'll be the same password they  
use everywhere, of course.

Quite honestly, I think any attempt to provide key storage on servers  
is just doomed - no doubt the odd client will do it (via private XML,  
or PEP/POP/PIP), but I don't think we should be encouraging it.

Key exchange between clients, however, is much simpler - we can  
perform a simple client-to-client authentication, securely bound to a  
peer-to-peer encrypted channel - as we would do for key verification  
- but this time use it to authenticate that you own both clients  
(devices, etc).

This should allow the expensive RSA keys to be copied securely from,  
say, desktop to mobile phone, or even between different clients on  
the same machine, reducing the likelyhood of lost keys.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Security mailing list