[Standards-JIG] Re: Re: JEP-0077: In-Band Registration
Michal vorner Vaner
michal.vaner at kdemail.net
Mon Jul 17 18:01:31 UTC 2006
On Mon, Jul 17, 2006 at 01:39:49PM -0600, Peter Saint-Andre wrote:
> Piotr Szturmaj wrote:
> >> RFC 3920 says we use SASL, which includes mechanisms such as Kerberos,
> >> DIGEST-MD5, and mutual authentication using X.509 certificates, etc. In
> >> general we are pushing people to use those methods rather than trying to
> >> upgrade the old methods documented in JEP-0078. If Kerberos, DIGEST-MD5,
> >> and X.509 are not secure enough for you, I suggest that you may have a
> >> future in IETF protocol development. ;-)
> > SALS is enought for authentication for me, you probably miss my whole point
> > ;-) All I want is storing hashes on disk instead of plain text passwords
> > (even encrypted).
It is impossible to do. If you use plain password in authentication, then
you can make a hash of it and compare it with the hash on server.
If you use some DIGEST-MD5 (or similar), it is like this:
1) server sends some random data to client
2) client puts the random data together with his password and does MD5
(actually, there is a bit more magic, but it is something like this).
Then sends it back.
Now, server needs to original, plain-text password to make the magic
with random data as well. If it stored it internally only, it could not
do the magic and could not check if it matches
> That's really an implementation issue, no?
> > Currently this is impossible because I need to specify
> > original password instead of hash (like in In-Band Registration).
What good it will be if you use a hash as the password. The attacker
does not need your original password in that case, he is OK with the
hash. The hash becomes effectively the password itself, for knowing it
enables you to log in.
> Support for JEP-0077 is optional, and even then support for the change
> password use case is optional.
> > I *must*
> > store original pass. Even if my client will hash it and use this hash like
> > password, I will lose possibility to login from other client. Lets assume
> > that passwords are hashed on server side, nobody (even administrator) can
> > retrieve password, that's ok. But anyone can do it on client side. All I
> > want is to make it impossible.
> As I say,I think that's a client implementation issue. Does anything in
> the protocols *force* the client to store the password in plaintext?
No, the authentication forces it to be saved in a way it can be
automatically obtained from it. (OK, client may not remember it at all
and ask the user every time, but the server actually must know the
password or the password must go trough the wire).
There is the possibility of certificates, GPG keys or whatever asymmetric
tricks. However, the problem is user can hardly go somewhere to his
friend and just type a password he remembers.
You can fool some of the people all of the time,
and all of the people some of the time,
but you can make a fool of yourself anytime.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards