Re: MD5 salt in pg_authid password hashes - Mailing list pgsql-general

From Adrian Klaver
Subject Re: MD5 salt in pg_authid password hashes
Date
Msg-id 201202151918.46419.adrian.klaver@gmail.com
Whole thread Raw
In response to MD5 salt in pg_authid password hashes  (Stefan Weiss <weiss@foo.at>)
Responses Re: MD5 salt in pg_authid password hashes  (Stefan Weiss <weiss@foo.at>)
List pgsql-general
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.klaver@gmail.com

pgsql-general by date:

Previous
From: dennis jenkins
Date:
Subject: Re: Postgresql 9.0.6 backends pruning process environment?
Next
From: John R Pierce
Date:
Subject: Re: Postgres 9.1 package for i.MX51X processor from Freescale