Si la entrada para la pregunta de seguridad es completamente digital, ¿la respuesta a una pregunta de seguridad debe estar marcada (o al menos cifrada) en el servidor de autenticación?
Supondré que el modelo contra el que intentas defenderte es cuando un atacante tiene acceso a la base de datos. Si ese es el caso, sí, es una mala idea si un atacante puede comprometer una cuenta al solo conocer esos detalles.
Mi consejo sería convertir la respuesta a mayúsculas, luego salt + hash it. Opcionalmente también recortarlo o contraer todo el espacio en blanco. Esto proporciona una medida de seguridad razonable sin reducir la usabilidad.
La respuesta es sí, siempre debes marcar esto .
¿Por qué tenemos hash de cosas como contraseñas? Dos razones: principalmente porque las personas a menudo usan la misma contraseña para muchas cosas diferentes, y además (es más bien un efecto secundario afortunado) para evitar que los atacantes inicien sesión cuando obtuvieron acceso a la base de datos de solo lectura.
Entonces, ¿no cree que el primer apellido de la madre o la mascota de la usuaria también son datos que él usaría en múltiples servicios? ¿O que potencialmente podría ser utilizado para ataques de ingeniería social? ¿O podría utilizarse para restablecer la contraseña y también obtener acceso?
Por esa razón, debe proteger las respuestas a las preguntas de seguridad contra los atacantes (¡y los administradores!) de la misma manera que lo hace con las contraseñas.
¿Por qué no cifrarlo?
El cifrado es reversible, hace posible el acceso a los datos mientras no sea necesario. Uno de los casos que está tratando de evitar protegiendo los datos de la base de datos, es un caso en el que el servidor esté comprometido, o cuando un interno tenga malas intenciones. En ambos casos, podrían usar la clave de descifrado para revertir la protección. Con hashing decente , esto ya no es posible.
Pero ¿qué pasa con la puntuación? No puedes hacer coincidir un hash a menos que sea exacto.
Las personas pueden usar varias palabras en una respuesta, y una vez que usan mayúsculas, otras veces pueden eliminar espacios entre palabras o poner un punto detrás de la oración ... así que sugiero que se normalice para al menos eliminar espacios. , elimine la puntuación y en minúsculas las letras mayúsculas.
Si lo tiene almacenado en texto sin formato o cifrado, debe escribir un algoritmo de comparación de todos modos. Ese algoritmo también tendrá que reducirse a una versión básica para poder decidir si coincide. Independientemente de lo que haría al escribir ese algoritmo de comparación (por lo tanto, cosas como minúsculas), debe aplicar antes del hash para obtener el mismo efecto.
Como se menciona en @Polynomial y @ B-Con , almacenar las preguntas de seguridad sin cifrar es peligroso si se pueden usar efectivamente como contraseña. Pero incluso si este no fuera el caso, no debería almacenar las respuestas de seguridad sin cifrar.
Las preguntas de seguridad comunes piden detalles personales, como "¿Cómo se llama tu madre?" (Suponiendo un sistema en el que no puede hacer preguntas personalizadas o donde el usuario simplemente elige una de las preguntas existentes). No es el único servidor que puede pedir ese detalle, la misma información puede usarse para comprometer la información en otros sistemas que tienen las mismas preguntas y respuestas de seguridad.
Aunque hay una respuesta aceptada y un consenso de que se debe eliminar, vale la pena señalar que hay casos en los que tal vez no sea deseable.
El más obvio es donde se le pide que seleccione los caracteres de la respuesta. Esto proporciona protección contra los ataques de reproducción. Pero no puede verificar la respuesta contra los datos de hash sin almacenar todas las combinaciones de hash posibles, y como resultado lo hace mucho, mucho más fácil de forzar el texto claro (es decir, pierde el beneficio de hashing). Normalmente, este enfoque se utiliza junto con una contraseña (con hash) para la autenticación.
Otro caso en el que esto podría ser aplicable es en el que es posible que desee proporcionar cierta lentitud en la validación, por ejemplo, permitiendo variaciones en el uso de mayúsculas. Un caso de uso para esto sería para un token que se usa con poca frecuencia, por ejemplo, en un restablecimiento de contraseña, pero debe aplicarse con precaución y junto con otros controles (por ejemplo, enviar un token de restablecimiento a la dirección de correo electrónico registrada en lugar de permitir un cambio inmediato de contraseña).
Estas son compensaciones de seguridad. Pero la seguridad perfecta es costosa y obstaculiza lo que los usuarios quieren hacer.
La forma más segura de restablecer la contraseña solo si se conoce la respuesta secreta, haga lo siguiente:
x={hash(password)}priv_S
donde priv_S es la respuesta secreta (clave privada) y se almacena la clave pública (pk_S).
Y para verificar hacer:
I=user's typed secret answer
x=={{x}pk_S}priv_I
Para iniciar sesión:
$username=<username>&&$hash=={x}pk_S
Esto permite la posibilidad de cambiar solo la contraseña si se conoce la respuesta secreta pero permite iniciar sesión sin ella.
Lea otras preguntas en las etiquetas passwords secret-questions