On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
<jltallon@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