[standards-jig] Refreshing the Thread: EDigest

Dave Smith dizzyd at jabber.org
Wed May 28 01:40:48 UTC 2003

Hash: SHA1

Amendment to my previous email -- Tijl, I agree completely now. Let's 
use the random numbers as you originally suggested. So edigest becomes:

edigest == SHA(stream id + SHA(random id + password))

The "why" of my sudden reversal...

Using just the "username" works fine for ensuring uniqueness across a 
single server, but that token could be used (as Tijl repeatedly pointed 
out) for attacks on other Jabber servers. I agree that would be bad.

Additionally, just the full JID causes problems with hosts that have 
multiple hostnames. By selecting a random id per user, I can 
authenticate as dizzyd against jabber.org or whatever other DNS names 
that my server is configured to support.

So the only conclusion is the random ID generated per user.

Duh. :)


On Tuesday, May 27, 2003, at 19:21 America/Denver, Dave Smith wrote:

> 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
> Version: GnuPG v1.2.1 (Darwin)
> iD8DBQE+1A8JYNE3chVHHsMRAvpDAKDq+/WrZP+eXRxSsy+46Cgeukq3lgCfecoI
> BjYK9924uekwwQtwfNCC/Dc=
> =Iu4+
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
Version: GnuPG v1.2.1 (Darwin)


More information about the Standards mailing list