Almacenamiento débil, cómo se ve y qué se concluye

Una contraseña guardada en texto plano se lee. En base64 también: base64 es una codificación, no una protección, y se deshace sin clave. Cifrada con AES y con la clave en el mismo servidor, se recupera con acceso al servidor. Las tres comparten una propiedad: la contraseña original se puede obtener. Para una contraseña eso es un fallo de diseño, porque el sistema nunca necesita recuperarla, solo comprobar que quien la escribe la conoce. Un hash con función de contraseñas es unidireccional precisamente por eso.

Abre SELECT * FROM usuarios_intranet y mira qué esquemas aparecen.

El hallazgo de una debilidad se mide en cuentas: no es lo mismo una cuenta que doce. Para el informe hay que contar qué cuentas tienen su contraseña recuperable, sumando todos los esquemas reversibles, sin repetir ni olvidar ninguno. Es un recuento sobre la lista, no una lectura de una celda.

Cuenta en la lista las cuentas cuyo esquema permite obtener la contraseña original.

Si dos cuentas guardan exactamente el mismo valor, es que usan la misma contraseña, y eso es visible sin descifrar nada. Es la señal de un hash sin sal: la sal existe para que esto no pase. Un auditor no necesita saber cuál es la contraseña; le basta con ver que el valor se repite para concluir que el almacén no tiene sal y que quien robe la tabla puede atacar de golpe a todas las cuentas que lo comparten.

Consulta las cuentas con MD5 sin sal con SELECT usuario, valor_guardado FROM usuarios_intranet WHERE esquema = 'MD5 sin sal'.

Una sal global —la misma para todas las cuentas— se parece a una defensa y no lo es del todo. Evita que sirvan tablas calculadas para el mundo entero, pero deja el resto del problema igual: dos cuentas con la misma contraseña siguen dando el mismo valor, y un hash rápido como SHA-256 se calcula millones de veces por segundo. El hallazgo tiene dos partes: el hash es rápido y la sal no es única. El arreglo es una función de contraseñas con sal por cuenta.

A veces el almacén está bien y el problema está al lado: la contraseña se escribe en claro en un registro. Un registro de acceso lo lee mucha más gente que la tabla de cuentas —soporte, operaciones, herramientas de análisis— y suele conservarse más tiempo y en más sitios. El hallazgo es independiente del algoritmo: da igual lo bien que se proteja la tabla si la clave pasa por el registro. El arreglo es dejar de registrar el campo y, si estuvo expuesta, tratarla como comprometida.

Lee SELECT * FROM registro_app y localiza la petición cuyo registro lleva una contraseña.