[Security] TLS Certificates Verification

Justin Karneges justin at affinix.com
Wed Aug 20 22:35:16 CDT 2008

On Wednesday 20 August 2008 03:10:54 Dirk Meyer wrote:
> "Remko Tronçon" wrote:
> >> The XMPP password and the key password should be something completly
> >> different.
> >
> > Yet, in practice, everyone who doesn't know much about security will
> > use the same password, and you're back to square one. You can try to
> > ask all clients to consistently refuse keys with the same passphrase
> > as the account (and vice versa, refuse account password changes that
> > are the same as the key), yet I doubt if that will work.
> 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.  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).

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.


More information about the Security mailing list