Tengo una aplicación que transmite la contraseña en texto sin cifrar. Estaba planeando usar el hash de la contraseña (SHA-512) como la clave para cifrar la contraseña de texto sin formato. A continuación, envíe el texto cifrado al servidor. la longitud de la contraseña es de un mínimo de 12 caracteres (incluidos los caracteres especiales) y un máximo de 20 caracteres.
¿Es este un mecanismo malo?
Con un pequeño ajuste, esto se puede hacer razonablemente seguro.
El problema con tu enfoque original es que el hash sería el mismo cada vez, por lo que es vulnerable a un ataque de repetición .
Si ajusta el protocolo para incluir un desafío variable , esto puede funcionar:
Este acuerdo es seguro contra ataques de reproducción y también evita que el servidor almacene una contraseña equivalente . Su principal vulnerabilidad es que un inicio de sesión capturado se puede utilizar para un ataque fuerza bruta sin conexión . Además, si está implementando esto en JavaScript, entonces el código de JavaScript podría ser interceptado y manipulado.
Ahora, aunque esto es interesante, debería hacerme eco del consejo de otras respuestas: no hagas rodar tu propio criptográfico
¿Es este un mecanismo malo?
Sí. Utilice SSL / TLS y no intente hacer rodar su propio esquema de criptografía .
Si su preocupación es transmitir la contraseña, entonces sí, absolutamente, este es un mal mecanismo. Su aplicación aún es vulnerable a una forma de pass-the-hash . Aunque la contraseña en sí no estará disponible para el atacante, la contraseña cifrada se puede interceptar y utilizar, para autenticarse.
Siempre apueste por el estándar:
Sí, esto es malo. Si todo lo que necesita el servidor para autenticarse es este hash (que nunca cambia), entonces tiene es su contraseña ahora. Esto no es mejor que enviar la contraseña sin cifrar, porque todo lo que necesita el atacante para suplantarlo es ese hash.
En cambio, si desea hacer un hash de las contraseñas para la transmisión, la forma de hacerlo es a través de un desafío- sistema de respuesta . De esta manera, el mismo hash nunca se envía dos veces. Pero esto no es una buena idea, porque ...
Es más importante que la contraseña no se almacene en su servidor. TLS / SSL es suficiente para prevenir cualquier tipo de ataque man-in-the-middle. Esa parte está resuelta, solo usa TLS y no te preocupes por eso. Pero do tiene que preocuparse por la piratería de su servidor y la filtración de su base de datos de contraseñas. La publicación de las bases de datos de contraseñas de otras personas está de moda en estos días, y usted no quiere ser uno de los capturados no hashing en su base de datos. Simplemente no hay excusa.
Por lo tanto, transmita sus contraseñas de texto sin formato dentro de una conexión cifrada, pero guárdelas con hash en el servidor. Si haces algo más, cualquier otra cosa, entonces lo estás haciendo mal.
Estaba planeando usar el hash de la contraseña (SHA-512) como la clave para cifrar la contraseña de texto sin formato. A continuación, envíe el texto cifrado al servidor.
No me importa si está utilizando SHA con una clave de 8192 bits, está intentando autenticarse con algo que viaja con la claridad de que alguien puede simplemente MITM así que tu respuesta es no. Cualquiera que haya trabajado con crypto (como las otras buenas respuestas aquí) le dirá que no intente rodar su propio crypto, a menos que realmente sepa lo que está haciendo, e incluso entonces hay muchas buenas API para eso.