Greetings, * Peter J. Holzer (hjp-pgsql@xxxxxx) wrote: > On 2020-05-06 09:28:28 -0400, Stephen Frost wrote: > > LDAP-based authentication in PG involves passing the user's password to > > the database server in the clear (or tunneled through SSL, but that > > doesn't help if the DB is compromised), so it's really not a good > > solution. > > Still a lot better than PostgreSQL's md5 scheme, which stores > password-equivalent hashes: If the database is compromised the attacker > has all hashes immediately and can use them to login. Intercepting > encrypted traffic even at the endpoint is much harder and can only > uncover passwords actually used. No, it's really not better because when you're talking about LDAP it's usually in reference to AD or similar centralized data store- so now you get a user's credentials not *just* for access to the particular PG database that you've compromised but across the *entire* AD environment. If you just compromise the md5 store (which you shouldn't really be using anyway, but whatever) then, sure, you can use that PW equivilant to get access into the DB that you've already compromised, and if they use the same username for other PG databases then maybe those too, but you don't get access to their VPN credentials, or the ability to RDP to any server they're allowed to log in to, or to the SQL server databases they have access to, or, or, or ... (at least, not without cracking the md5 hash, which requires at least a little bit of additional effort and we do "salt" it with the username so it's not completely trivial... still, please, please, please use SCRAM for local logins, at least..) Thanks, Stephen
Attachment:
signature.asc
Description: PGP signature
