PostgreSQL: métodos de autenticación de contraseña

Hay varios métodos de autenticación basados ​​en contraseña disponibles. en PostgreSQL Estos métodos funcionan de la misma manera, pero difieren en cómo se almacenan las contraseñas de los usuarios en el servidor y en la forma en que la contraseña proporcionada por un cliente se envía a través de la conexión. Los métodos son los siguientes:

El método de la contraseña envía una contraseña de texto no cifrado y, por lo tanto, es susceptible a los ataques de «olfateo». Si es posible, debe evitarse. Si la conexión está protegida por encriptación SSL, las contraseñas a menudo se usan de manera segura. Aunque la autenticación de certificado SSL podría ser una opción mucho mejor si se cuenta con el uso de SSL.

Crypt() puede ser una función Unix común y fácilmente disponible para probar, bueno, el cifrado. La función crypt acepta los siguientes dos argumentos:

1. La contraseña para cifrar.
2. Sal que se utilizará al cifrar.

Para que PostgreSQL esté disponible para nosotros, siempre tenemos que usar la función gen_salt. Usamos crypt nuevamente para autenticar a un usuario, pero esta vez pasamos los siguientes argumentos:

1. Contraseña enviada.
2. La contraseña encriptada que ya tenemos en la base de datos.

Si la contraseña coincide, crypt devuelve el mismo valor que el que ya tenemos en la base de datos. Es bueno siempre que crypt() solo se use para cifrar contraseñas locales, como era el uso original, pero se rompe cuando intenta comunicarse a través de varios sistemas a través de una red.

El enfoque md5 emplea un mecanismo menos confiable para el desafío-respuesta. Evita la detección de contraseñas y evita que las contraseñas se almacenen en texto sin formato en el servidor, pero no brinda protección si un atacante logra robar un hash de contraseña del servidor. Además, el algoritmo hash MD5 actualmente no se considera seguro contra determinados ataques. Además, el método md5 no se puede usar con la función db_user_namespace.

SCRAM es el único mecanismo SASL actualmente en vigor. Se describe en detalle en RFC 7677 y RFC 5802 respectivamente.

Cuando se usa SCRAM-SHA-256 en PostgreSQL, el servidor ignora el nombre de usuario que el cliente envía en el primer mensaje del cliente. En su lugar, se utiliza el nombre de usuario que ya se envió en el mensaje de inicio. PostgreSQL proporciona múltiples codificaciones de caracteres, mientras que SCRAM especifica que se use UTF-8 para el nombre de usuario, por lo que es posible que no sea posible representar el nombre de usuario de PostgreSQL en UTF-8.

La especificación SCRAM dicta que la contraseña también está en UTF-8 y se procesa utilizando el algoritmo SASLprep. Sin embargo, PostgreSQL no requiere el uso de UTF-8 como contraseña. Cuando se establece la contraseña de un usuario, se procesa con SASLprep como si estuviera en UTF-8, sin importar la codificación particular utilizada. Sin embargo, si no es una secuencia de bytes UTF-8 legal o contiene secuencias de bytes UTF-8 que están prohibidas por el algoritmo SASLprep, la contraseña sin procesar se usará sin procesar SASLprep en lugar de un error.

PostgreSQL también contiene un conjunto de métodos de autenticación relacionados con las contraseñas:

• ldap
• radio
• pam
• bsd

Con respecto al cliente y el protocolo, estos son equivalentes al método de autenticación de texto simple “contraseña”. La única diferencia es que el servidor no compara la contraseña con lo que está almacenado en pg_authid sino con el servicio externo respectivo. Esto evita que la contraseña se almacene en texto claro en la base de datos, pero aún tiene todos los demás problemas asociados con este método. Usar SSL para la conexión PostgreSQL y configurar el servidor LDAP y la conexión de forma segura alivia muchas de estas preocupaciones, pero no será tan infalible como SCRAM.

Dependiendo de las necesidades del entorno, la seguridad y la criptografía son difíciles. Pero con SCRAM, PostgreSQL usa estándares públicos reconocidos y ahora está en una buena posición para adaptarse en el futuro.