¿Usar MySQL 'encrypt' / crypt () para almacenar contraseñas?

Question

¿Usar MySQL 'encrypt' / crypt () para almacenar contraseñas?

#1 de Zonk (1 votos)

3

Me han asignado la tarea de implementar una instancia de FTP con un backend de MySQL para almacenar los inicios de sesión de los usuarios.

Buscando en línea encontré Pure-FTPD, que en papel es genial. Sin embargo, la documentación indica que solo permite estas opciones de hashing / encriptación para las contraseñas:

#MYSQLCrypt md5, cleartext, crypt() or password()

MD5 y el texto sin cifrar están fuera de los requisitos, la contraseña () aparentemente debe evitarse (según la documentación de MySQL), lo que deja a crypt ().

El uso de crypt () para insertar un valor en una base de datos se basa en 'cifrar', que a su vez es una llamada al sistema crypt (). Consulte: enlace

Entonces, la pregunta es: ¿qué tan seguro es este método de encriptación para almacenar datos confidenciales, dice wikipedia que crypt () -

"En lugar de cifrar la contraseña con una clave, que tendría permitido recuperar la contraseña del valor cifrado y la clave, usó la contraseña como una clave, y la base de datos de contraseñas Contuvo el resultado de cifrar la contraseña con esta clave ".

Lo que parece genial, sin embargo, no puedo encontrar ninguna información en la base de datos de "contraseñas" de la que habla, el valor insertado también se reduce a un máximo de 16 bits si recuerdo correctamente, lo que realmente no Parece seguro.

Cualquier comentario sobre esto sería apreciado, gracias!

passwords hash encryption databases

pregunta Johndoes 24.10.2015 - 15:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords hash encryption databases

¿Por cuánto tiempo se almacena la información en Facebook? [cerrado] ¿Qué formulario SAQ debo usar para el cumplimiento de PCI DSS?

score 1 · Answer 1

Si lees la documentación : SHA1, MD5 y la contraseña de MySQL () son solo es compatible con motivos heredados y scrypt o crypt (3) se recomienda. Sin embargo, eso realmente no respondería a tu pregunta, así que permíteme enfatizar cuál elegiría.

crypt (3) Esta es la función de hashing de contraseñas de Unix (algunos lo llaman cifrado). Este es un cifrado DES modificado que utiliza un sal de 12 bits basado en el reloj del sistema, para la diversificación por usuario. Lo realmente negativo de esta función es que solo toma ocho caracteres ASCII (es decir, 56 bits) como clave. Esa clave se utiliza para cifrar una cadena de 64 bits de 0 y el cifrado DES modificado. La salida se cifra nuevamente con la clave y este procedimiento se repite 25 veces. La repetición fue elegida para frenar los ataques de diccionario. Sin embargo, el craqueo de contraseñas de criptografía (3) no es realmente un gran problema y depende en gran medida de la seguridad de la contraseña de sus usuarios. Tenga en cuenta que esta solución se remonta a la década de 1970 y todos los sistemas Unix / Linux modernos utilizan algoritmos hash modernos, como SHA-256 o SHA-512.

scrypt Este método fue desarrollado por Colin Percival, quien identificó que el hashing de contraseñas era predominantemente de CPU, pero no de memoria. El problema cuando un algoritmo de hash de contraseñas solo es difícil para la CPU es que, cuanto más CPU haya, más rápido podrá forzarlo. El factor limitante es la memoria y la potencia de la CPU. Por lo tanto, scrypt consta de una serie de funciones que extienden el enfoque de CPU duro en un enfoque de memoria dura.

Conclusión Si tiene la opción de elegir cualquiera de los dos métodos de protección con contraseña, me gustaría utilizar Scrypt en lugar de Crypt (3). La razón es que crypt (3) ya está en desuso y scrypt ofrece más protección contra los ataques de fuerza bruta. Sin embargo, también depende de la cantidad de usuarios que su solución debe atender. Naturalmente, una CPU, la función de memoria dura no solo utilizará más recursos durante el forzado, sino también durante la autenticación normal en comparación con las funciones que no ofrecen esto.