[Standards-JIG] Re: Re: JEP-0077: In-Band Registration

[Dave Cridland]

On Mon Jul 17 21:21:48 2006, Peter Saint-Andre wrote:
> Chris Mullins wrote:
> > Piotr Szturmaj Wrote:
> > >> All I want is storing hashes on disk instead of >> plain text 
> passwords (even encrypted). > > That's always been an issue with 
> the legacy authentication types - the
> > need to store the real password. Storing a hash + salt is 
> certainly
> > preferable. 
> Well, I've been chatting with Piotr via IM, and his concern does 
> seem to
> be that the password gets stored on the client machine in 
> plaintext. He
> thinks that Jabber systems will be more secure if the credentials 
> are
> stored as a hash on the client machine. That way, even if a hacker 
> gains
> control of my machine, they'll have only the hash -- which makes it
> trivial for the hacker to log into my Jabber account of course, but 
> at
> least the hacker won't be able to discover the plaintext (which I 
> might
> have used for other accounts or whatever).

This is precisely the purpose of DIGEST-MD5, and I do precisely this 
for my SASL implementation which handles clients for a number of 
SASL-based services. Of course, the hash can be brute-force cracked, 
eventually. Tijl seemed to suggest that you needed to keep the nonce 
the same, or something, but you don't - that only affects the final 
hash, not the intermediate.

>  Also Piotr says this would
> make it easier to switch between clients (I wouldn't have to give 
> the
> new client my plaintext password).

The DIGEST-MD5 intermediate hash can also be shared between clients, 
potentially, but it'd be better to share the SASL implementation if 
possible, and have that handle authenication entirely for the client.

> system through encrypted files or whatever). Better, I think, to go
> forward into SASL land (X.509 certificates for end users, anyone?) 
> than
> to shore up jabber:iq:auth a la "edigest" or to attempt 
> modifications to
> the DIGEST-MD5 SASL mechanism (which is outside of our control, 
> anyway).
> But as always, maybe I'm missing something...

I *think* DIGEST-MD5's revision is about to go through Last Call, but 
I might be wrong, I don't track SASL-WG. But in any case, there's no 
modification needed here at all.

JEP-0078 *is* weak, but we knew that. JEP-0077 has no impact on 
storing plaintext passwords, and is reasonably future-proof against 
new mechanisms.

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