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