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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue May 27 23:04:17 UTC 2003


Dave Smith <dizzyd at jabber.org> wrote on 28-5-2003 0:57:29:
>
>
>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.

You seemed to suggest it a little though. But ok, your registration is 
just as bad as any other :) 

>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 X
>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".

Just XOR everything you write to the DB and read from it with "Dizzy". 
Or write it to native MS Word 97 format inside an OLE object. 
Seriously, the *only* advantage your method has is protection it has 
from the obscurity of the idea you are proposing. Name me one other 
advantage it has when that goes away, besides admins gniffeling at your 
choice of password. This "obscurity-protection" is already not present 
for other Jabber systems using edigest in your propasal. Is this worth 
depricating digest for? some temporal obscurity? 

Do you agree with me that security through obscurity is not the right 
path for a standerdized jabber-authentication protocol? Do you agree 
with me that what you propose is nothing like what *NIX uses for 
authentication? DO you agree that with the proposed enhancenment by 
Casey and/or me, edigest would have some actual functionality besides 
the security-through-obscurity part? 

I you think security through obscurity is a good idea I have a better 
plan to prevent storing passwords in plaintext. Just don't store 
anything! Just let everyone in who tries. I mean, what fool would try 
and log into a server without a password? Just don't tell anyone ;) 

>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. 

*cough*.

quote:
"
I'd recommend that we go ahead an use <edigest> and deprecate usage of 
<digest>. This path ensure backwards compatibility.
"

>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.

Ofcourse, Zero-K was a disaster. But that's another point. The point 
is, in the current form, it doesn't add enough to justify breaking 
every client outthere, or as most would feel I think, it's not even 
worth implementing. 

Consider some of the proposed additions to your protocol, and it might 
be worth something as an extra option. And what are your objections to 
them? 

Since then it would actually to some degree prevent the admin from 
using your password (or some useable form of that) to crack other 
accounts, including those that use the same auth-mechanism, without 
using obscurity as a technique. That's what you wanted to do in the 
first place was is it not? It might even be usefull to implement :) 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list