¿Qué tan seguro se consideraría este método para el almacenamiento de contraseñas?

Question

¿Qué tan seguro se consideraría este método para el almacenamiento de contraseñas?

#1 de Fleche (7 votos)
#2 de Mark (6 votos)
#3 de Matthew Elvey (0 votos)

0

Ok, actualmente estoy almacenando las contraseñas de la forma más segura que se pueda imaginar. Con uso de cifrado y hash. Las contraseñas las genera primero el usuario como texto sin formato con una longitud mínima de 6 caracteres alfanuméricos hasta 24 caracteres alfanuméricos.

Después de las contraseñas, el valor de texto sin formato se ejecuta contra MCRYPT. Principalmente el cifrado TWO_FISH con IV aleatorio en modo ECB. Una vez que se realiza, el texto sin cifrado se enlaza a la función Hash que también agrega SALT a través de $saltVar = dechex(mt_rand(0, 2147483647)) . dechex(mt_rand(0, 2147483647));

Todo está en su lugar. Las contraseñas cifradas con SALT + se procesan mediante SHA-256 y luego se vuelven a aplicar las siguientes 15536 rondas. Creando una contraseña relativamente segura.

En mi opinión personal, esta es una manera suficiente de proteger los datos, ya que en parte no se está utilizando una clave, no hay forma de descifrar esto, aparte de volver a ejecutarla con una contraseña de texto sin formato ingresada por el usuario y crear un cálculo temporal hash de la cadena de contraseña, después de lo cual la cadena se puede hacer coincidir con la cadena en la base de datos.

Nunca usaría esto para ningún otro dato, pero para la contraseña creo que esto es suficiente. Sin embargo, todavía me gustaría algo de crítica profesional, en cuanto a lo que sea mi forma de proteger la contraseña de texto sin formato, es segura o no, y o tal vez cómo puedo mejorar lo que ya tengo si está bien. Y mientras estoy en ello, ¿recomendaría usar TWO_FISH o cambiarlo por SEARPENT?

Gracias de antemano.

passwords encryption cipher-selection php

pregunta 0111010001110000 22.05.2014 - 04:59

fuente

3 respuestas

Lea otras preguntas en las etiquetas passwords encryption cipher-selection php

Detalles de la vulnerabilidad de Dropbox [cerrado] ¿Por qué las "redes no seguras" todavía son una cosa en la era de HTTPS? [cerrado]

score 7 · Answer 1

Generalmente es una mala idea inventar tus propios algoritmos de seguridad. Como ya ha dicho, no sabe si esto es seguro. Puedes creerlo, y quizás incluso encuentres a alguien que esté de acuerdo contigo. Pero eso no significa mucho.

Existen soluciones establecidas como bcrypt que han demostrado ser teóricas y prácticas a lo largo de muchos años. Podemos estar bastante seguros de que esos son de hecho seguros. Entonces, ¿por qué no aprovechar esto y usar bcrypt?

Con respecto a su propio algoritmo:

En primer lugar, no veo por qué limitaría al usuario solo de 6 a 24 caracteres alfanuméricos. Esto hace que sea imposible reforzar la contraseña con caracteres especiales o utilizar una frase de contraseña larga.

La función mt_rand() produce números aleatorios débiles de fuentes de baja entropía como la hora del servidor y la identificación del proceso. El manual de PHP lo señala explícitamente . Un total de 8 bytes tampoco es demasiado.

No puedo comentar si su esquema de hash es correcto, pero dado que las PC de valores pueden calcular miles de millones de hash SHA-256 por segundo , 16,000 rondas de nuevo no son mucho.

score 6 · Answer 2

Veo dos problemas obvios con tu sistema:

1) 24 caracteres no es mucho. Una buena frase de contraseña es más memorable que una contraseña, y compensa la baja entropía por carácter del texto legible al tener una gran cantidad de caracteres, de 30 a 60 caracteres o más. ¿Hay alguna razón para el límite?

2) El cifrado no proporciona ninguna seguridad sobre el hash. Si el atacante puede robar la lista de contraseñas, es probable que también puedan robar la clave de cifrado y la IV (como nota al margen, el modo ECB no usa una IV). Básicamente tienes un hash fijo de 15,537 rondas, lo que puede ralentizar a los atacantes hoy en día, pero a medida que las computadoras se vuelven más rápidas, se vuelve más débil.

¿Existe alguna razón por la que no pueda usar una solución estándar de la industria, como la bcrypt de una fuerza inherentemente lenta? ?

score 0 · Answer 3

No. Siento que no había necesidad de leer en el pasado donde mencionas que se permiten contraseñas de 6 caracteres. Eso es demasiado corto. Incluso si necesita que contengan caracteres alfa y numéricos, eso no es suficiente. No tardará mucho en ejecutar un diccionario de todas las contraseñas alfanuméricas de 6 caracteres a través de su algoritmo usando cada valor de sal en la base de datos. Las otras respuestas proporcionan otras buenas razones para no usar su sistema, pero esta es una relativamente simple y obvia.