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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue May 27 20:05:01 UTC 2003


Dave Smith <dizzyd at jabber.org> wrote on 27-5-2003 21:56:04:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>On Tuesday, May 27, 2003, at 13:23 America/Denver, Tijl Houtbeckers 
>wrote:
>
>> The "amount" we win with this is very small. It doesn't protect your
>> own jabber account, and if you use the same password for another 
>> jabber account it doesn't protect that either. On top of that, any 
>> other program that uses the same mechanism is vonurable too. Or is 
>> it part of the plan that all non-jabber developers will recognize 
>> what a bad idea it is and never implement it?
>
>Ouch.
>
>Look, the idea here is to fix something that should have been fixed a 
>long time ago. This isn't rocket science. It is neither less, nor more 
>secure for authentication/registration than the current method -- but 
>it DOES provide A way to avoid storing a password in plaintext.
>
>For those of you who are saying "it _just_ obscurity", consider that 
>it's important that we don't store plaintext passwords for the SAME 
>reason that *nix doesn't store plaintext passwords. Even if people 
>know the hash, it doesn't do them a whole lot of good.

Unix doesn't use the hash as authenitcation. It only uses a hash to 
store the password. Once you use the hash to authenticate you lose most 
of the advantages of not storing the password in plaintext. Imagine 
*NIX would allow me to authenticate using the hash it actually stores. 
That would mean that if I'm the BOFH at a *NIX server where you have a 
shell acount I could log into every other shell accounts you have where 
you use the same password. In other words, there's a good reason *NIX 
does exactly *not* what you propose here. 

The *least* you could do, is concat a random key to the password before 
you hash it and store both the hash and the random key in the database, 
and send this key to the client before it SHA1's the password. Then you 
at least protect other accounts on the server (unless the admin changes 
the password, wich you would notice),and other servers/applications. 
Then we solve some actual issues, without having to worry other people 
will think it's a good idea. 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list