[Security] TLS Certificates Verification
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
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,
> 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
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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Security