Procedimiento seguro para establecer credenciales SCRAM en un rol PostgreSQL

[josedelleonn]

Estamos preparando un rol técnico con permisos mínimos para consultar el catálogo comercial de Open-Ear HN.

• Proyecto: ---
• PostgreSQL: 17.11.
• Rol: oe_openear_catalog_reader_v1, actualmente NOLOGIN y NOBYPASSRLS.
• Sus ocho políticas RLS están instaladas y verificadas estructuralmente. La prueba funcional autenticada del lector está pendiente.
  Antes de habilitar LOGIN, necesitamos confirmar cómo establecer su contraseña SCRAM sin exponer el verificador en registros o telemetría.
  Evidencia local
  Realizamos una prueba aislada con PostgreSQL y psql 17.11 para Windows, utilizando exclusivamente una contraseña ficticia:
• psql \password solicitó la contraseña de forma oculta y terminó correctamente.
• No encontramos la contraseña en claro en argumentos, consola, archivos temporales ni registros del servidor.
• Sin embargo, con log_statement=ddl, el registro local incluyó la sentencia de cambio de contraseña y el verificador SCRAM completo.
  Este resultado corresponde al laboratorio, no demuestra una exposición en Supabase. El informe adjunto contiene únicamente indicadores sanitizados, sin contraseñas ni verificadores.
  Evidencia del proyecto Supabase
  El 26 de octubre de 2026, a las 13:11 UTC, consultamos exclusivamente metadatos mediante conexión directa con TLS verify-full, dentro de una transacción READ ONLY finalizada con ROLLBACK.

Observamos:
log_statement = ddl
log_min_error_statement = error
log_destination = csvlog
logging_collector = on

pg_stat_statements.track = top
pg_stat_statements.track_utility = on

pgaudit.log = none
track_activities = on

session_preload_libraries = supautils
supautils.privileged_role = supabase_privileged_role
La lista supautils.privileged_role_allowed_configs incluye, entre otros, log_statement, log_min_error_statement y pg_stat_statements.*.

Las comprobaciones ordinarias de privilegio SET no mostraron autorización para esos parámetros. Entendemos que esto no descarta por sí solo una delegación adicional mediante supautils, cuya aplicabilidad efectiva no hemos probado.

No hemos ejecutado cambios de logging, establecido una contraseña para el lector ni habilitado LOGIN. Tampoco hemos demostrado si Supabase elimina el verificador de las estadísticas o de la telemetría administrada.
Consultas

1. ¿Cuál es el procedimiento oficial recomendado para establecer una contraseña SCRAM sin registrar su verificador?
2. ¿Puede nuestro contexto administrativo utilizar controles temporales por sesión mediante supautils? ¿Qué controles serían necesarios y suficientes?
3. ¿Qué protección o redacción aplica Supabase a estas sentencias en registros DDL, errores, pg_stat_statements, pg_stat_activity y telemetría administrada?
4. ¿Existe una vía oficial de aprovisionamiento preferible a ALTER ROLE o psql \password para evitar esta exposición?
   No solicitamos cambios globales, desactivar auditoría ni privilegios adicionales. Buscamos el procedimiento mínimo compatible con la seguridad administrada de Supabase.

Gracias por su orientación.

[aymansalkhatib]

No soy del equipo de Supabase, así que los puntos 2 y 3 (supautils y la telemetría gestionada) solo los puede confirmar Supabase. Pero sobre el comportamiento de PostgreSQL hay varias cosas que reducen bastante el riesgo y que pueden verificar ustedes mismos:

1. \password ya es el procedimiento recomendado

Lo que observaron en el laboratorio es exactamente lo esperado. psql \password calcula el verificador SCRAM en el cliente (PQencryptPasswordConn) y envía ALTER ROLE ... PASSWORD 'SCRAM-SHA-256$4096:...'. La contraseña en claro nunca llega al servidor; solo el verificador. Es lo que recomienda la documentación de ALTER ROLE precisamente para no exponer la contraseña en registros. No existe en PostgreSQL una vía que evite también que el verificador pase por el servidor, porque el servidor necesita almacenarlo.

2. Qué permite (y qué no) un verificador filtrado

El verificador contiene salt, iteraciones, StoredKey = H(ClientKey) y ServerKey (RFC 5802). Para autenticarse como cliente hace falta ClientKey, que no se puede obtener de StoredKey. Así que quien lea el verificador en un log no puede iniciar sesión directamente. Lo que sí permite es:

• un ataque de diccionario offline (4096 iteraciones de PBKDF2 es poco), y
• si además captura un intercambio SCRAM completo de ese rol, recuperar ClientKey. Con TLS verify-full eso no es realista.

Por eso la mitigación práctica es la entropía: generen una contraseña aleatoria larga (por ejemplo 32 bytes en base64, openssl rand -base64 32), y la fuerza bruta offline deja de ser viable aunque el verificador quede en un log.

3. Controles por sesión

Pueden comprobar directamente si su rol puede silenciar el registro solo para esa sesión, sin cambios globales:

BEGIN;
SET LOCAL log_statement = 'none';
-- si este SET da error de permisos, no está delegado para su rol
ROLLBACK;

Si funciona, en la sesión real: SET log_statement = 'none';, luego \password oe_openear_catalog_reader_v1, y cierran la sesión. Si no funciona, el registro DDL es algo que solo Supabase puede controlar.

4. Verificar después

Tras fijar la contraseña pueden comprobar lo que quedó en las estadísticas:

SELECT query FROM pg_stat_statements WHERE query ILIKE '%password%';

y, si aparece el verificador, SELECT pg_stat_statements_reset(...) sobre esa entrada (si su rol tiene permiso). Para registros y telemetría gestionada, la pregunta a Supabase debería ser concreta: retención y acceso a los logs de Postgres del proyecto.

Recomendación

Contraseña aleatoria de alta entropía + \password + (si está permitido) SET log_statement = 'none' en esa sesión. Con eso, aunque el verificador llegara a un registro, no sirve para autenticarse y no es atacable por fuerza bruta. Y si en algún momento sospechan exposición, la respuesta es simplemente rotar la contraseña con el mismo procedimiento.