A stab at implementing better password hashing, with mixed results

Hello all,

A while ago, on pgsql-general, I raised the issue that the password
storage employed by postgres is a little weak and promised I'd look
into this during the holidays, so here are my findings.

Implementing bcrypt instead of md5 is indeed rather straightforward;
just move the pgcrypto blowfish code into Postgres and tweak a few
things. However, there seems to be no way to get the md5-based
authentication working with any different kind of storage than
plaintext or the existing md5 storage because it requires access
to the salted MD5 password hash. Backwards compatibility can
only be guaranteed for passwords using this storage. Adding bcrypt
means (oddly enough) that the authentication system will become *less*
secure, requiring plaintext password logins, making SSL mandatory.
However, since the existing authentication is not terribly secure
anyway that may not be considered a big loss (except maybe for
passwords popping up in accidental local network data dumps..).

Implementing a more secure challenge-response based algorithm means
a change in the client-server protocol. Perhaps something like SCRAM
(maybe through SASL) really is the way forward for this, but that
seems like quite a project and it seems to dictate how the passwords are
stored; it requires a hash of the PBKDF2 algorithm to be stored.

One problem with a better algorithm is that for CGI-like web scripts,
connection speed is important. The CGI model (which is also employed
by Perl and PHP, AFAIK) is in direct opposition to the security
requirement that password hashes should take long to create or verify;
if it takes long, this is a constant extra factor for all web requests
(unless advanced connection pooling is used, perhaps). The
authentication method may also have an impact if it needs expensive
calculations.

I'm unsure how useful this bcrypt patch is, since it won't be acceptable
as-is, but I've attached it just in case. If it is decided that this
should be integrated after all, it needs more work:

- There's no way to specify which hashing system to use for new
passwords; I've ripped out the md5 hashing. I think this requires
a change in the user management statements.
- There's no way to specify (the log 2 of) the number of rounds to
run the blowfish algorithm. This is extremely important as it
directly impacts the time it takes to set up a connection, like
I said above, and some admins might like to increase the work
factor for increased password protection.
I think this might be a run-time server variable and/or possibly
an option in the user management statement.
- Ideally, pgcrypto could re-use this, so that there is no duplicate
copy of the bcrypt code. The salt generation is less strong than
pgcrypto's, which uses openssl AFAICT, so that might need some extra
hooks. The crypt code could also be exposed as an SQL function.
- Currently, if a client uses md5 auth to connect as a user who has
a bcrypted password it simply means the correct password will be
rejected. There's no clean way to handle this, as far as I can see;
giving more feedback will probably require a change in the protocol
and will give away more information than we want: you'll know a user
exists and even that the password isn't stored in plaintext or md5.

The conclusion is that switching to bcrypt requires a handful of extra
changes that I don't know how to make, and has the consequence of
*requiring* plaintext password authentication or a change in the
protocol. If it's decided to go forward with this anyway, I'm willing
to help out, but implementing a completely new authentication system
goes a little over my head, I'm afraid.

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth