Обсуждение: SCRAM-SHA-256, is it possible to retrieve enough information from PGserver (pg_authid etc) to perform authentication as a client
Hi guys,
I am new to PostgreSQL, so sorry for maybe stupid question. I am working on some application implementing Frontend/Backend PG protocol and one of the goals - having only "admin" users credentials (like postgres user) be able to retrieve enough information from PG server (for example, from pg_authid table) to perform authentication for any user created in PG (without any user interaction, so we don't know the user's password).
It is fine for plain text or md5 authentication types, but it looks impossible for scram-sha-256, since looking at the RFC 5802 and libpq source code, the information presented in pg_authid (SCRAM-SHA-256$<iteration count>: <salt>$<StoredKey>:<ServerKey>) is enough only to perform server side authentication for external client and not enough to authenticate on the PG as a client. This actually sounds logically and reasonable in terms of infosec, so could you please that it is not possible or maybe there is any way to achieve that?
Thanks in advance,
Vladimir
>>>>> "Vladimir" == Vladimir Soldatov <solardatov@gmail.com> writes: Vladimir> Hi guys, Vladimir> I am new to PostgreSQL, so sorry for maybe stupid question. I Vladimir> am working on some application implementing Frontend/Backend Vladimir> PG protocol and one of the goals - having only "admin" users Vladimir> credentials (like postgres user) be able to retrieve enough Vladimir> information from PG server (for example, from pg_authid Vladimir> table) to perform authentication for any user created in PG Vladimir> (without any user interaction, so we don't know the user's Vladimir> password). It's an explicit goal of SCRAM to make it impossible to use the server's stored authentication data to actually authenticate from a client (without first breaking the preimage resistance of the hash function). Specifically, the authentication exchange proves to the server that the client knows key_c, but the server only stores H(key_c); the server can validate the client message just by applying the hash function, but the correct value of key_c can't be determined in advance on the server without a successful preimage attack on H(key_c). The right way to allow a privileged user to operate as if they were someone else is to use SET ROLE or SET SESSION AUTHORIZATION rather than actually trying to log in as the other user. -- Andrew (irc:RhodiumToad)