Buena práctica: almacenar contraseñas en general

Navega tus respuestas
-3

Hoy tengo una pregunta totalmente teórica: ¿cuál es la "mejor" práctica para almacenar contraseñas? [Lo mejor en términos de seguridad y rendimiento]

Por lo general, especialmente los desarrolladores de PHP tienden a almacenar las credenciales de los usuarios en texto sin formato o como hash, utilizando MD5 o SHA1 y sus sucesores. Los desarrolladores web y cocineros de software más inteligentes incluso agregan un poco de sal a la contraseña antes de hacer hash.

Los desarrolladores de Android por lo general parecen almacenar en texto sin formato, por lo que he visto hasta ahora, confiando ingenuamente en el concepto de derechos de usuario de Android, incluso argumentando que enraizar los dispositivos es culpa del usuario.

Hay muchas prácticas diferentes por ahí. Texto sin formato para esas aplicaciones, donde los desarrolladores dependen de la seguridad de la plataforma o quieren que el usuario recupere su propia contraseña. Hashing donde los desarrolladores confían en la integridad de su algoritmo de hash, ignorando los ataques de colisión, etc. Hashings salados donde los desarrolladores leen que el hashing simple es algo malo debido a las tablas de arco iris. Incluso hay algunos desarrolladores que utilizan la criptografía real, pero generalmente la clave se puede recuperar en algún lugar.

Mi idea fue utilizar AES (o [aún no está rota] la criptografía simétrica en general, como el pez globo y así sucesivamente), que encripta la contraseña rellenada (para ocultar la longitud de la contraseña) con un prefijo de sal. La Clave sería la contraseña del usuario, lo que debería hacer imposible recuperar y verificar la contraseña sin la contraseña.

Me pregunto por qué la práctica habitual difiere de esa idea, entonces, ¿dónde está la culpa? La complejidad no debería ser tan alta, porque existen buenas implementaciones de AES, incluso implementaciones de hardware. No hay colisiones hash posibles en esto.

Entonces, ¿tengo razón en que nadie podría usar un volcado de datos con esas contraseñas para otra cosa que no sea la fuerza bruta? [Por supuesto, hay otros ataques, que son independientes del almacenamiento de contraseñas de back-end, no son el tema de esta pregunta]

¿Puede ser que esta idea sea bastante similar y esté relacionada con bcrypt, pero sin múltiples iteraciones?

    
pregunta pmedia 11.02.2013 - 00:06
fuente

2 respuestas

7

Una buena práctica es no almacenar las contraseñas sino algo que se utiliza para verificar una contraseña. Eso se llama hashing .

Su propuesta es solo una función hash personalizada de AES, que no fue diseñada para eso. Los algoritmos criptográficos personalizados y caseros son la perdición de la seguridad. Para. La resistencia de AES como una función de encriptación dice (casi) nada acerca de su resistencia como un elemento en una función de hash (excepto por esa cosa rara llamada ataques de claves relacionadas que no importan para el cifrado, pero pueden matar una propuesta de función hash, y AES es un tanto endeble en esa área).

Su idea es bastante similar a bcrypt, excepto que evita todo lo que realmente hace de bcrypt un buen algoritmo, es decir, la lentitud configurable (las "iteraciones") y la sal , siendo ambos importantes para la seguridad.

Las colisiones no tienen nada que ver con los esquemas de seguridad de hashing de contraseñas. Estos trabajan en la resistencia a preimágenes .

    
respondido por el Tom Leek 11.02.2013 - 00:14
fuente
4

Básicamente, has propuesto hacer un hash de una sola vía a partir de un cifrado de bloque usando el esquema: 

H(x) = AES(x,x)

¿Qué tiene de malo? Todo lo que está mal con el uso de una función hash estándar, como el SHA en bruto *, más el hecho de que es un diseño personalizado. En el mejor de los casos, no mejora en una función hash normal, en el peor de los casos tiene una falla que una función hash estándar no tendría.

(Tenga en cuenta que no hay nada inherentemente en el diseño de hashes basados en cifrados en bloque. Se puede hacer, aunque no estoy respaldando el esquema propuesto aquí).

Como mínimo, los hashes de contraseña deben estar con sal para evitar ataques de diccionario, y tener un factor de trabajo escalable que permita al hash hacer que el atacante gaste una cantidad configurable de energía haciendo su ataque.

    
respondido por el B-Con 11.02.2013 - 00:19
fuente

Lea otras preguntas en las etiquetas

¿Cómo se utilizan los softwares bancarios a través de Internet? Me enviaron esto, ¡pero no sé el método de cifrado! [cerrado]