On Wednesday, February 15, 2012 6:34:21 pm Stefan Weiss wrote: > From the manual: > | Because MD5-encrypted passwords use the role name as cryptographic > | salt, renaming a role clears its password if the password is > | MD5-encrypted. > > In backend/commands/user.c > > if (!pg_md5_encrypt(password, stmt->role, strlen(stmt->role), > encrypted_password)) > elog(ERROR, "password encryption failed"); > new_record[Anum_pg_authid_rolpassword - 1] = > CStringGetTextDatum(encrypted_password); > > I don't understand this. Why was the role name chosen as a salt? Apart > from the problem that the hash becomes unusable when a role is renamed, > roles names are very poor salts. Given how relatively predictable they > are, the hash could just as well be left unsalted.
When you alter the role name you are told the password has been cleared. It would be fairly easy to wrap the rename and the setting of the password in a transaction. > > There is a comment in libpq/md5.c which more or less acknowleges this: > "Place salt at the end because it may be known by users trying to crack > the MD5 output." Ignoring for the moment that cracking PG passwords is > probably not very common, the position of the salt does little to > prevent attacks. > > A random salt would eliminate both weaknesses. The only explanation I > can come up with is that the current method of hashing has been kept for > historic reasons, as changing to a random salt would break existing hashes. > > Or is there something else I've overlooked? Yes: http://www.postgresql.org/docs/9.0/static/encryption-options.html " Encrypting Passwords Across A Network The MD5 authentication method double-encrypts the password on the client before sending it to the server. It first MD5-encrypts it based on the user name, and then encrypts it based on a random salt sent by the server when the database connection was made. It is this double-encrypted value that is sent over the network to the server. Double-encryption not only prevents the password from being discovered, it also prevents another connection from using the same encrypted password to connect to the database server at a later time. Encrypting Data Across A Network SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. The pg_hba.conf file allows administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions. " > > > regards, > stefan > > > PS: Strictly speaking, the expression "MD5-encrypted" in the manual is > incorrect - MD5 is a hashing algorithm, not an encryption algorithm. > </nitpick> -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
