Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers