Re: reducing our reliance on MD5 - Mailing list pgsql-hackers

On 02/11/2015 03:55 PM, Claudio Freire wrote:
>> On 02/11/2015 03:39 PM, Claudio Freire wrote:
>>
>> [snip]
>> Seems the risk of someone either lifting pg_authid from disk or by hacking
>> the system and being postgres, thereby accessing passwords stored
>> somewhere
>> else, is actually the bigger problem. But also one that should be
>> reasonably
>> easy (TM) to fix in a backwards compatible way? (just rewrite with a new
>> hash whenever the password is changed, but keep reading md5 until they are
>> all replaced.
>> Problem with all challenge-response authentication protocols, is that
>> the hash you have stored has to match the hash you use on the wire
>> protocol.
>>
>> It's not like you can store a SHA and provide MD5 authentication.
>>
>> Yes, except that you can do "fallback to plaintext" if the client requests
>> (S)CRAM-SHA and you have (S)CRAM-MD5 instead, allowing for some
>> interoperability and backwards compatibility in the process: pre-change
>> libpq/JDBC could authenticate using password to a server with just
>> SCRAM-SHA512 credentials.
>>
>> In any case, just storing the "password BLOB"(text or base64 encoded) along
>> with a mechanism identifier would go a long way towards making this part
>> pluggable... just like we do with LDAP/RADIUS/Kerberos/PAM today.
>
> Wait... you mean falling back to storing plaintext or falling back to
> transmitting plaintext over the wire?

Fallback to authentication using plaintext ... if the client is old. And 
might as well require SSL before allowing that --- the sane solution, 
definitively.    But let us not forget that there exist environments where even 
non-SSL plaintext is acceptable when the network is secure/trusted. We 
should not prevent that usage if users need it (performance or 
management reasons) if at all possible, I think.

This would imply adding a fallback "or plaintext negotiation when 
possible" to the new mechanisms.
We could even restrict that behaviour to "hostssl" entries in pg_hba.conf

> 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?

There are many organizations out there happily using 3rd party 
applications that they can not modify easily and this change would break 
them gratuitously.    - New policy. Introduce new hashes, update credentials (when possible!)    - New applications can
benefitfrom the newer/better security 
 
immediately    - Client app that uses older libpq/JDBC. Doesn't understand the new 
mech    - ... and now the user is left with a broken app and no easy way back
    alternative: old app has to authenticate itself just as if 
pg_hba.conf said "password", possibly restricted to doing so over an 
SSL-secured connection.


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?

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.
Please note that, AFAICS, adding a second entry to pg_hba.conf with the 
fallback mechanism won't work.
    Now I come to think of it, the behaviour I just proposed would help 
users and maintainers of connection poolers to achieve seamless upgrades 
while increasing security (the pooler would negotiate using the newer 
mechanism with postgres using the client-provided password)



Thanks,
    J.L.