[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns

Iain Shigeoka iain at jivesoftware.com
Tue May 27 17:45:02 UTC 2003

On Tuesday, May 27, 2003, at 10:33 US/Pacific, Dave Smith wrote:

> On Tuesday, May 27, 2003, at 11:12 America/Denver, Casey Crabb wrote:
>> I don't think this is any more secure than just sha1(StreamID +
>> password). What happens is that sha1(password) is
>> password-equivalent.
>> At some point sha1(password) has to travel over the line; at this
>> point it can be sniffed. Or, if you have access to the server's spool
>> you can just read it out of there.
> This technique doesn't solve a replay problem -- it's not intended to. 
> It is designed to ensure that the password is not human readable. 
> Consider the case where a corporate executive selects their Jabber 
> password, and they reuse one that they already use elsewhere. If the 
> password is stored in plaintext, a malicious sysadmin (yes, I know 
> you're supposed to trust the admin) can use that plaintext password to 
> login to other company systems. So the idea with this algorithm is to 
> obscure/hide the password sufficiently that the admin may find the 
> hash, but determining the actual text that was typed in will be 
> sufficiently difficult. Most companies are very skittish about storing 
> a plain-text password in their databases, this provides a nice 
> alternative, without requiring a special "server key" to encrypt the 
> password (or some such madness).
> Does that make sense?

Yup. As long as that's made clear in the docs that make sense and seems 
worthwhile to add. Since it is such a trivial change, we should 
strongly deprecate the old digest method in favor of this one.


More information about the Standards mailing list