[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
mass at akuma.org
Wed May 28 22:17:50 UTC 2003
Won't they still have to send the plaintext password if they are using
register to create an account that they will later use SASL to
We have talked about this before in the past; it really doesn't increase
security at all, except that users who use the same password everywhere
are less likely to have all their accounts compromised when the jabber
server is taken out - but it doesn't solve the problem with other
servers being compromised, someone sniffing them sending the plaintext
password to a website, other jabber servers supporting this same
password format, someone listening to the registration, and many other
Not to mention we are extending the 'simple' and 'old' auth method to be
less simple and now completely incompatible. I sincerely hope the only
thing using jabber:iq:auth six months after the RFC is released are
nonmaintained clients, and these simple software clients which
apparently can't handle base64. We have no purpose in extending _around_
SASL to get the authentication methods we need; if someone needs this
sort of authentication system, a new SASL mechanism should be registered
with the IANA to handle it.
Dave Smith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (Darwin)
> -----END PGP SIGNATURE-----
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards