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

David Waite 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 
authenticate with?

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.

-David Waite

Dave Smith wrote:

> 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
>> 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?
> Diz
> Version: GnuPG v1.2.1 (Darwin)
> K89VS4TniS3T695eCrbvYc8=
> =tHB0
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list