On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón <jltal...@adv-solutions.net> wrote: >> Both seem a step backwards IMO. > > Hmmm... as opposed to breaking applications innecesarily when simply > enabling SSL/TLS would not make it insecure? or when users don't really need > it?
No, as opposed to cases where people are already using md5 authentication effectively. > Moreover, requiring everybody to change all passwords and clients *at once* > seems like a very poor decision towards allowing for graceful upgrades and > make rolling changes back possible, right? I wasn't advocating for what. I was just pointing out that implementation of SCRAM was an all-encompassing endeavour, in that you have to attack both password storage and the transmission protocol. For instance, if you tell me I can do SCRAM, I'll be happy to enable it if my lib has support for it. But if you add "oh... to use it, you must store plaintext on pg_authid", I'd change my mind. Because you cannot do SCRAM while storing md5. And there lies the issue I'm pointing out. I'm not giving solutions. Except, maybe, that if it were to be explicit for user creation: CREATE ROLE someone WITH ENCRYPTED PASSWORD '1234' USING 'pbkdf2-hmac-sha1' ; This would preclude authentication using md5, of course, but it would be expectable and under admin control. And I myself would use it. > Additionally, there are cases where passwords are not stored in plaintext > anywhere (required to be able to generate new credentials) and updating all > clients at once simply isn't possible. I agree -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
