[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
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
>> 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