Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
>>That's what I told him. I think his concern about pre-computed hashes
>>is the only real issue, and give 'postgres' is usually the super-user, I
>>can see someone pre-computing md5 postgres hashes and doing quick
>>comparisons, perhaps as a root kit so you don't have to do the hashing
>>yourself. I personally don't find that very compelling either.
>>
>>
>
>Lessee ... we'll include a complete password hash table in a root kit,
>which will be used at a point where we've already managed to read
>pg_shadow but are somehow still lacking the ability to do anything else
>we could want to the database ... nope, not very compelling.
>
>
>
>
[bugtraq removed - I don't think this belongs there, at least at this stage]
/etc/shadow is supposedly only readable by root (or things that are
setuid root). If you have root you already own the box. Yet we store
passwords there hashed with random salt.
My understanding is that Stephen would like a system where clear
passwords are never stored. He's right in saying that our "encrypted"
passwords are in effect cleartext, as a malicious client would only ever
need to know the hashed pw to gain access, and not the original
cleartext. Of course, adding random salt won't change that, and you are
quite right in saying that the random salt would have to be sent as part
of the challenge.
There's a choice between protecting the password over the wire via a
challenge/response system, and protecting it in storage. Postgres has
quite reasonably chosen the former. Stephen says "Well, I can protect
the wire comms via ssh or IPSEC, and I'd like storage protection too."
That also seems reasonable, although I don't think the sky is really
falling in.
Lastly, I have seen Jan say several times (on IRC) that mission-critical
DBs should not be exposed to untrusted networks, but always protected by
appropriate middleware. I could not agree more.
cheers
andrew