[standards-jig] Refreshing the Thread: EDigest
dizzyd at jabber.org
Wed May 28 01:21:13 UTC 2003
-----BEGIN PGP SIGNED MESSAGE-----
Ok, time for humble pie! I have a large, heaping slice and, boy! It
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the Standards