* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> With the documentation text clarified, this patch fixes the actual
> documentation problem that both 'password' and 'md5' supporte encrypted
> pg_shadow passwords, while only crypt does not. Applied to 8.0.X and
> HEAD.
Great, thanks. Here's a suggestion to replace the last two sentences:
These methods differ in how the password is sent across the network and
in the meaning of what is stored in pg_shadow.
The 'password' method sends the password across the network in
plaintext which could allow someone sniffing the network to retrieve
it unless there is encryption being done in the transport layer (ie:
SSL or IPSEC). Using the 'password' method the server will either
compare the provided password to what is stored in pg_shadow or, if
the 'with encrypted password' option was used to md5 the password in
pg_shadow, the server will concatenate the user's name to the
password and perform an md5 hash and compare that to what is in
pg_shadow.
With the 'md5' method the server will send will send a randomly
generated salt to the client which will then concatenate the user's name
to the password, perform an md5 on that result, then concatenate the
result of the md5 to the salt provided by the server and will then md5
that. The client sends the result of that md5 to the server which then
reads what is in pg_shadow, which must be md5 using 'with encrypted
password', concatenates that with the random salt sent to client,
performs an md5 on the result and compares that to what was sent by the
client. Note: this makes the md5 hash stored in pg_shadow what is known
as a 'password-equivilant', which means that an attacker does not need
the original password to authenticate to PostgreSQL, the attacker needs
only the hash which is stored directly in pg_shadow. In other words, if
pg_shadow is compromised an attacker can then log into the database as
any user without any effort.
Thanks, Stephen
