From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Vince Vielhaber <vev(at)michvhf(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, "Sverre H(dot) Huseby" <sverrehu(at)online(dot)no>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: You're on SecurityFocus.com for the cleartext passwords. |
Date: | 2000-05-06 17:29:01 |
Message-ID: | 10623.957634141@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>>> The goal here was to make wire sniffing unproductive, and because the
>>>> server supplied the salt to be used by the client, you can't just
>>>> re-use a sniffed password you saw on the wire.
Good point. Are we trying to make the password challenge proof against
wire sniffing? I think that might be an unreasonable goal. People who
are concerned about sniffing attacks ought to be using something like
SSL to encrypt the *entire* connection (and/or a better auth protocol
than passwords, in the first place...). I repeat my prior comment that
the data in the database is likely to be just as valuable as the
password.
> Right now the client receives a random salt from the server, it uses
> that salt to crypt the password, then send that back for comparison with
> the clear-text password we store in the system.
> What if we:
> store the password in pg_shadow like a unix-style password with salt
> pass the random salt and the salt from pg_shadow to the client
> client crypts the password twice through the routine:
> once using the pg_shadow salt
> another time using the random salt
> and passes that back to the server. The server can use the pg_shadow
> copy of the password, use the random salt make a new version, and
> compare the result.
Use the random salt to make a new version of what, exactly? If the
server doesn't have the cleartext password, it can't make a crypted
password that will correspond to any randomly chosen salt either.
> This has the huge advantage of not requiring any new crypting methods on
> the client. It only requires the crypt to happen twice using two
> different salts.
A serious objection to both this and the MD5 proposal is that it'd
create a cross-version incompatibility between clients and servers.
We were just fending off complaints about 6.5-to-7.0 incompatibilities
that were considerably less serious than being unable to connect at all,
so how well do you think this'd go over?
I think we should try to stick to the current protocol: one salt sent
by the server, one crypted password sent back. The costs of changing
the protocol will probably outweigh any real-world security gain.
We could get some of the benefits of a random salt if we were willing
to enlarge the pg_shadow entry a little bit. Suppose that we allow
N different salt values to be sent by the server (crypt(3) only allows
4096 possible salts anyway, but I'm thinking N in the range of 100).
When a password is set, crypt the password with each of these and store
*all* the results in pg_shadow. Then we have the right crypted password
available to compare to the client response, and an attacker still has
a relatively low probability of having sniffed the right password.
BTW, I hear "MD5" being chanted like a mantra, but someone will have
to explain to me what it does that avoids the sniffed-crypted-password
problem...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-06 17:30:24 | Re: You're on SecurityFocus.com for the cleartext passwords. |
Previous Message | Vince Vielhaber | 2000-05-06 17:25:18 | Re: You're on SecurityFocus.com for the cleartext passwords. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-06 17:30:24 | Re: You're on SecurityFocus.com for the cleartext passwords. |
Previous Message | Vince Vielhaber | 2000-05-06 17:25:18 | Re: You're on SecurityFocus.com for the cleartext passwords. |