Cómo verificar que las contraseñas no estén almacenadas en un formato legible

5

Estoy escribiendo un plan para auditar mi política de contraseñas, y me quedé atascado en uno de mis controles de políticas, lo que me aseguraba de que no se almacenara una contraseña en un formato legible.

¿Cuál es la mejor práctica que debo seguir para auditar este control? Sabiendo que estaré auditando casi 40 componentes.

    
pregunta user78455 12.06.2015 - 05:53
fuente

3 respuestas

7

Aunque el almacenamiento de contraseñas en texto claro es algo malo, algunos tipos de "ofuscación reversible" (por ejemplo, la codificación Base64 o el "cifrado ROT13") no son mucho mejores, y deberían detectarse también.

La forma correcta de auditar el almacenamiento de contraseña y el método de verificación es mirar la especificación , es decir, el documento que indica qué algoritmo se utiliza y con qué parámetros. Si ese documento existe, simplemente léelo. Si ese documento no existe, asuma lo peor; Desde el punto de vista de la auditoría, el comportamiento no especificado es tan malo como el comportamiento débil.

Mirar la base de datos es similar a la ingeniería inversa: mientras que tiende a funcionar (de hecho, se puede aprender muchas cosas a través de la ingeniería inversa), también indica que los diseñadores del producto no están colaborando con los auditores, y eso hará que la auditoría sin sentido.

(En un apuro, como auditor, podría arreglárselas con una copia del código fuente y ver cómo el código procesa las contraseñas. El código fuente no es un buen sustituto para la documentación adecuada, pero aún es mucho mejor que la inferencia de una mirada superficial a una base de datos.)

    
respondido por el Tom Leek 12.06.2015 - 14:47
fuente
2

La mejor manera de verificar esto es revisar el código fuente. Debe verificar que la aplicación use un hash fuerte, cómo usa Salt y no registre datos confidenciales. Además, si la base de datos de contraseñas admite la actualización de hash, asegúrate de tomar nota del esquema de hash más débil que se sigue aceptando y de cuántos usuarios aún tienen hash más antiguo / más débil.

El inconveniente de auditar solo los datos de la base de datos es que puede ser difícil / imposible distinguir entre un campo de contraseña con hash (bueno) o cifrado (no bueno).

También debe auditar el registro de la aplicación, asegúrese de que la aplicación no registra las contraseñas (por ejemplo, si hay excepciones durante el inicio de sesión).

    
respondido por el Lie Ryan 12.06.2015 - 14:35
fuente
2

Inspeccionaría el almacenamiento de contraseñas para ver si hay patrones notables (por ejemplo, "password1234"), o crearía un 'usuario de prueba' con una contraseña conocida y vería si esa contraseña está en texto sin cifrar en los almacenes de contraseñas.

La última opción permite la posibilidad de pruebas automatizadas.

Sin embargo, principalmente, este tipo de auditoría solo debe realizarse una vez y luego de los cambios en la forma en que se almacenan las contraseñas. Simplemente puede verificar manualmente que las contraseñas estén encriptadas (eso significa que tienden a tener la misma longitud y no "palabras").

EDIT

Tom Leek tiene la forma más correcta de auditar el manejo correcto de las contraseñas, lo que indica una debilidad en su control: debe tener un control que se ocupe de una serie de formas aceptables para manejar el almacenamiento de contraseñas, que es más sólido que simplemente ' no se puede leer'.

Dicho esto, es también importante mirar el almacenamiento para ver si se está aplicando de la forma esperada.

    
respondido por el schroeder 12.06.2015 - 07:03
fuente

Lea otras preguntas en las etiquetas