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

Matt Tucker matt at jivesoftware.com
Tue May 27 18:01:24 UTC 2003


> 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.

As someone else pointed out, this is the illusion of security and not 
actual security. The easiest way to decide to not implement this change 
is to realize that it's the *exact* same system that we have now. The 
proof is that the client could use the current system and just send 
sha1(password) instead of password to implement the same thing as 
edigest. In general, users shouldn't be using the same password for 
everything. In reality, they sometimes do. So, if you're worried about 
this and don't want to do encryption in the db, just implement the plain 
text password hiding client-side. The other benefit is that it doesn't 
break backwards compatability.


More information about the Standards mailing list