Robert Haas <robertmhaas@gmail.com> writes:
> Although the patch was described as relatively easy to write, it never
> went anywhere, because it *replaced* MD5 authentication with bcrypt,
> which would be a big problem for existing clients.
Right. The client end of it is the elephant in the room in any discussion
of improving the password hash algorithm.
> 2. We'd have to figure out how to get support for the new algorithms
> into libpq. This actually seems a good bit harder than doing it on
> the server-side, because I don't think libpq has any dynamic loading
> facilities the way the server does.
If you think libpq is the only problem, or even the main problem,
on the client side then you have seriously misjudged the situation.
There are multiple clients that do not use libpq at all, JDBC being
the poster child here.
Another thing we need to keep in mind besides client compatibility
is dump/reload compatibility.
I think it would be wise to take two steps back and think about what
the threat model is here, and what we actually need to improve.
Offhand I can remember two distinct things we might wish to have more
protection against:
* scraping of passwords off the wire protocol (but is that still
a threat in an SSL world?). Better salting practice would do more
than replacing the algorithm as such for this, IMO.
* scraping of passwords directly from the pg_authid table or from
a pg_dump dump. In this case it's not so much that we are worried
about preventing the scraper from accessing the database (he's
evidently in already) as that we'd like to prevent him from recovering
the original cleartext, since the user might've used that same password
elsewhere. (Bad user, but nonetheless something we might try to
protect against.) Again, more salt seems like it might go a lot further
than just changing the algorithm.
Are there other goals?
regards, tom lane
