¿Es segura la autenticación basada en contraseña de Postgres?

Si usa SSL, entonces lo que hace PostgreSQL está bien. Si no usa SSL, pero sigue haciendo la autenticación en la red, entonces PostgreSQL apesta. Sus juegos con MD5 no tienen ningún valor, pero no porque usen MD5. MD5 tiene sus propios problemas, pero ahí solo lo están utilizando mal.

Con la autenticación "cleartext password", el cliente muestra un nombre de usuario y una contraseña, y el servidor los acepta si coinciden con lo que el servidor almacenó.

Con la autenticación "md5", el cliente muestra un valor (que es el hash MD5 de la concatenación de la contraseña y el nombre de usuario) y el servidor lo acepta si coincide con lo que el servidor almacenó.

Para que lo veas: en ambos casos , el cliente muestra un montón de bytes al servidor, siempre con la misma secuencia. Basta con que un atacante toque en la red para observar estos bytes, y luego se conecte al servidor y envíe los mismos bytes para recibir la entrada. Que los bytes sean el resultado de un hash MD5 es completamente irrelevante aquí. Se dice que este hash MD5 es equivalente de contraseña . Siempre que la conexión pueda ser escuchada (es decir, sin SSL), la seguridad se irá por el desagüe.

Consulte esta página para obtener más información sobre el cálculo del MD5. Lo llaman "cifrado", que no es en absoluto (el hashing no es cifrado).

Incluso podríamos argumentar que el uso de este MD5 reduce la seguridad: cuando se usa una contraseña de texto sin formato, se puede reenviar a otro servidor de autenticación (usando Kerberos, LDAP, ...) y ese servidor de autenticación luego podría emplear fuertes técnicas de almacenamiento (consulte hashing de contraseña ). Con el hash MD5 específico de PostgreSQL, esto no puede aplicarse. Cuando se utiliza el método de autenticación "md5", DEBE estar en contra de una tabla en la base de datos que contiene todos estos valores "md5" tal como están. Un atacante que puede tener en sus manos, por ejemplo, una cinta de copia de seguridad o un disco antiguo, obtendrá inmediatamente muchas cuentas gratuitas en la base de datos.

Y, insisto, nada en todo esto tiene que ver con las debilidades criptográficas MD5. Todo esto aún se aplicaría si se reemplazara MD5 con SHA-512.

Sí, usar MD5 es seguro. Cuando un cliente quiere autenticarse, el servidor envía un valor de sal aleatorio. El cliente usa ese valor, junto con la contraseña para generar un hash MD5. Debido a que se usa una sal aleatoria, un atacante no puede usar un ataque de diccionario. Además, dado que la sal se cambia cada vez que un cliente se autentica, esto no es una capacidad para reproducir las solicitudes de autenticación antiguas.

Detalles aquí en la sección AuthenticationMD5Password

TLDR. Puede ser seguro si lo configura correctamente y usa buenas contraseñas largas.

1. En postgres, md5 auth-method significa hashing del lado del cliente (discusiones: 1 , 2 ), que hace hashes contraseña equivalente . Un hash en la db se compara con un hash recibido de un cliente. Un atacante puede usar cualquier hash de la tabla pg_shadow robada directamente, sin siquiera gastar tiempo para descifrar el md5.

Es mucho más seguro asumir que los hash serán robados eventualmente y evitar el hashing del lado del cliente.

En realidad, solo puede mirar el código, es bastante simple: enlace < - enlace directo a esta línea:

 if (strcmp(crypt_client_pass, crypt_pwd) == 0)

Mira qué pasa cuando port->hba->auth_method == uaMD5 . Sí, uno no puede interceptar un hash de texto claro, de nuevo está salado y picado. Pero cuando es robado por cualquier otro ataque, puede usarse directamente sin grietas.

2. Como era de esperar, puede usar el hashing md5 del lado del servidor con postgres utilizando password auth-method y create user whatever with encrypted password .

  

Estos métodos funcionan de manera similar, excepto por la forma en que la contraseña   se envía a través de la conexión, es decir, hash MD5 y texto claro   respectivamente.

Use SSL para proteger la contraseña de texto simple. Probablemente debería saber cómo se almacena su hash: la sal se reutiliza:

 /* Encrypt user-supplied password to match stored MD5 */
 if (!pg_md5_encrypt(client_pass,          // const char *passwd
                     port->user_name,      // const char *salt
                     strlen(port->user_name),
                     crypt_client_pass))   // char *buf

Uno incluso podría crear nombres de usuario desechables generados al azar para usarlos como sal, pero no estoy seguro de que sea una buena idea, esto es propenso a errores.

Si bien la recomendación general es migrar desde md5, aún no está roto para el hashing de contraseñas. Pregunta relevante: Por qué ¿la gente sigue utilizando / recomienda MD5 si está roto desde 1996?

No utilice contraseñas cortas. Las contraseñas aleatorias largas y de alta calidad siguen siendo seguras.

Para una estimación rápida, estos enlaces (desafortunadamente, bastante antiguos) tienen algunos números:
enlace < br> enlace

Actualización : gracias a RhodiumToad del canal #postgresql en irc.freenode.net por aclarar que md5 aún no está roto para el hashing de contraseñas, las buenas contraseñas largas salvarán el día.