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