[Standards-JIG] Re: Re: JEP-0077: In-Band Registration
dave at cridland.net
Mon Jul 17 20:57:50 UTC 2006
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
> > 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
> stored as a hash on the client machine. That way, even if a hacker
> 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
> least the hacker won't be able to discover the plaintext (which I
> 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
> 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?)
> 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,
> 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
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards