Greetings,
* Peter J. Holzer (hjp-pgsql@hjp.at) 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
