[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
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
>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
>> 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.
I'd recommend that we go ahead an use <edigest> and deprecate usage of
<digest>. This path ensure backwards compatibility.
>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
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
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 :)
Software Engineer @ Splendo
More information about the Standards