* 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
signature.asc
Description: Digital signature