Обсуждение: 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)