[standards-jig] Refreshing the Thread: EDigest

Dave Smith dizzyd at jabber.org
Wed May 28 01:21:13 UTC 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

Ok, time for humble pie! I have a large, heaping slice and, boy! It 
looks great!

First off, let me say that both Casey and Tijl were on the right track 
with their suggestions-- I should have read their comments more 
carefully. I apologize for my negligence and bull-headedness, and hope 
that this email will start to make amends.

If you would, allow me to start this thread from scratch (kinda)....

- --

One of the topics that has been discussed lately is the need for 
"encrypted" storage of passwords on the Jabber server. Currently we 
(the Jabber community) only support auth mechanisms that require a 
clear-text password to be available (digest/plaintext) on the system. 
SASL, while useful in this regard, may take a while to adopt and get 
deployed. As such, perhaps we should consider a Jabber "native" 
alternative that will solve this problem and provide a reasonable 
alternative to parties who are not interested in implementing SASL.

To this end, I would like to propose a new, alternative element into 
the jabber:iq:auth namespace. This element would be the "edigest" 
element, and would use a slightly different mechanism for encoding the 
password. The algorithm would be as follows:

edigest == SHA1(stream ID + SHA1(password + username))

* Casey and Tijl suggested the password + username, obviously.

When a user registers, they will provide the SHA1 hash of the password 
and username (in that order) -- this would necessitate an addition to 
the jabber:iq:register namespace as well. The system will store the 
hash as the login token and use it for authentication.

Note that the "username" value is the username part of the user's JID 
that they are attempting to authenticate against. By following the 
password in the hash process, it will ensure that even if two users 
utilize the same password, they will always wind up with a different 
hash value.

Note that this mechanism does NOT address the problems inherent with 
registration, especially where the login token is passed over the wire 
in un-encrypted form. The idea here is to simply "obscure" login token 
such that it is useless  to any person who gains access to the system 
(legitimate or otherwise). "Useless" here means that no one could take 
this login token and use it to access other, non-Jabber systems.

Note also that this mechanism is MUTUALLY EXCLUSIVE to the 
digest/plaintext password authentication types, since the actual 
password is never stored on the server.

Finally, note that edigest is an ALTERNATIVE To digest -- it is up to 
the system administrator to make the deployment choice of disabling 
digest and/or plaintext authentication.

- --

Whew, I think that about covers all the big discussion points that came 
up today.

Tijl, I avoided the random number stuff simply because the username 
part of the JID can fill that role, without requiring any extra 
storage. Sorry I didn't give you more credit before.

Casey, good idea.

As for those who say "what's the point? No one is going to implement 
it!" I can only respond that I know of at least two servers, and four 
clients that will get support for edigest as soon as the Council 
approves the JEP. This doesn't mean that everyone will use it, 
certainly, but it does provide an alternative for those who don't wish 
to store plaintext passwords.

If you still don't like the proposal, feel free to contribute a counter 
proposal that satisfies these same requirements.

That pie sure was good.

Diz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+1A8JYNE3chVHHsMRAvpDAKDq+/WrZP+eXRxSsy+46Cgeukq3lgCfecoI
BjYK9924uekwwQtwfNCC/Dc=
=Iu4+
-----END PGP SIGNATURE-----




More information about the Standards mailing list