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

Dave Smith dizzyd at jabber.org
Tue May 27 22:57:29 UTC 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Tuesday, May 27, 2003, at 16:06 America/Denver, Ralph Siemsen wrote:

> Dave Smith wrote:
>
>> digest auth == SHA1(stream id + password-plaintext)
>> edigest auth == SHA1(stream id + SHA1(password-plaintext))
>> This would mean that one never sends the plaintext password over the 
>> wire, even for registration.
>
> That is true.  But you are sending only a variation with no challenge 
> posed from the server.  So, anyone with a packet sniffer can capture 
> the  SHA1(password-plaintext) as it is transmitted.  This includes 
> your friendly sysadmin who you wish you could trust.  The sniffed 
> hashed password is all it takes for another client to duplicate the 
> same connection - they do not need to know the original password.

Agreed. I'm not trying to solve the provisioning problem, however, as 
noted in my previous 3,308 emails. edigest provides NO advantages to 
digest when it comes to registration -- however it also does not 
provide any DISadvantages.

> So, as was pointed earlier, the effect of hashing the password is no 
> different than sending the plain password.  It is just a different 
> string being sent around.  Anyone can see this string, either by 
> sniffing the traffic or by looking at the spool file.  And then they 
> can login.

Yes, yes. I completely agree -- but we're not trying to solve that 
problem.

> So, you have to weigh the efforts of changing all the clients against 
> this supposed "increase" in security that in fact is exactly the same 
> as what we have with digest right now.
> The issue of the password being sniffed cannot be fixed, wether it is 
> encrypted or not, without the use of something like SSL or SASL, and 
> that requires client changes - which will take time to implement and 
> adopt over the millions of users.
>
> So focus on the other problem - that of the password being stored 
> plaintext on the server.  There are a variety of ways to avoid that, 
> all of which do not require any changes to the clients to implement, 
> and will not break any existing clients.

OK, this is indeed the problem -- how does one store a password on a 
server in encrypted form:
1. without changing our existing authentication methods..and..
2. without relying on a global, server encryption key?

I posit that this is the simplest, best way to approach the problem. 
I'm open to alternatives, however, alternatives that really accomplish 
something.

Let me be clear, edigest does NOT address the problem of sniffing or 
malicious admin-ing -- I recognize it has the same weaknesses as 
storing the password in plaintext, with regard to those problems. 
HOWEVER, it does provide the system with an alternative encoding of the 
password that is not plaintext.

Is it "just obscurity"? I suppose, if you call hashing a plaintext 
password so it's not visible or readily usable for any other 
application than Jabber "obscurity".

In response to Mr. Walp's post...

On Tuesday, May 27, 2003, at 16:03 America/Denver, Nathan Walp wrote:

>> digest auth == SHA1(stream id + password-plaintext)
>>
>> edigest auth == SHA1(stream id + SHA1(password-plaintext))
>>
>> This would mean that one never sends the plaintext password over the
>> wire, even for registration.
>
> Which BREAKS the ability to do plaintext or digest auth.  It's 
> backwards
> IN-compatable, making it not the right way to go about things.

Dude, read the entire thread. This is an ALTERNATIVE mechanism. Yes, if 
you use edigest, you probably can't use digest and/or plaintext. The 
same was true of Zero-K, back in the day. Our auth system supports 
multiple, occasionally mutual exclusive authentication mechanisms. 
There's NOTHING wrong with that.

Diz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+0+1ZYNE3chVHHsMRAssdAJ47Fg4k4rXKvYpfFbSS6aw8Z1tP1QCgpd1U
ObnnSy7Gm0mhwDOSsnDK3xM=
=T4Hu
-----END PGP SIGNATURE-----




More information about the Standards mailing list