Diseñar una contraseña para el sistema de autenticación / registro

Navega tus respuestas
1

Estoy diseñando un sistema de registro / autenticación de usuario para un sitio web y se me ocurrió este diseño para autenticación basada en contraseña.

Me gustaría saber si esto es razonable. (ignorando las cookies para las credenciales de almacenamiento en caché, auth, etc.)

Algunas cosas las incorporé al diseño, pero no estoy seguro de cuánto "ayudan" a la seguridad:

  1. en caso de que la base de datos del servidor esté comprometida, hashedPw se envíe desde el cliente para que saltedSecret se pueda volver a verificar. (hashedPw no se almacena en el servidor)

  2. desafío (chalSecret) para evitar un ataque de repetición

  3. el costo de scrypt se puede ajustar con el tiempo, pero como espero usar una implementación de scrypt de javascript en los navegadores, tal vez no sea una característica tan buena.

Otra pregunta es si puedo asegurar fácilmente el envío inicial de saltedSecret durante el registro del usuario, pero supongo que el uso de HTTPS será lo suficientemente bueno para eso.

Si hay formas en que pueda simplificar esto, hágamelo saber.

NOTA: consulte la sección de edición a continuación para ver los cambios que simplifican este diseño.

EDITAR:Algunascosasquemeocurrierondesdequepubliquéesto:

  1. TLS protege contra ataques de repetición , por lo que puedo eliminar toda la sección de desafío.
  2. en el lado del servidor, debería (como mínimo) almacenar un hash del saltedSecret. Lo mejor es guardar un scrypt de él. Esto tiene un buen efecto secundario al eliminar el requisito del usuario de enviar el hashedPw durante el inicio de sesión.
  3. Nuevo diagrama con estos cambios:
pregunta JasonS 02.04.2015 - 01:25
fuente

1 respuesta

1

El problema que veo es que, si bien se hace un gran esfuerzo para evitar transmitir la contraseña de los usuarios, saltedSecret se ha convertido esencialmente en una contraseña.

La principal amenaza para una contraseña transmitida es que un hombre en el medio (MITM) podrá observarlo (en ausencia de cualquier otra forma de cifrado) e iniciar sesión en su sistema.

Si observamos cómo un MITM podría explotar su sistema:

  1. Observan saltedSecret desde un registro o un inicio de sesión (flujo 1 o 7)
  2. Hacen una solicitud de inicio de sesión y reciben un aviso de challengeSalt y chalCost antes de que se hayan autenticado. (flujo 2)
  3. Utilizan el saltedSecret que saben para generar chalSecret e iniciar sesión (flujo 7)

Sin embargo, puedes mitigar esto parcialmente almacenando saltedSecret y no enviando hashedPw o saltedSecret nuevamente en el flujo 7. Aún serías vulnerable del saltedSecret inicial en el flujo 5.

Esto sigue siendo problemático porque también necesitas un esquema de salado y hash en el lado del servidor si almacenas saltedSecret . De lo contrario, si su base de datos se ve comprometida de alguna manera, pueden usar estos valores para iniciar sesión en su sistema. Sin embargo, al incluir el saltedSecret , no podrá reconstruir chalSecret en el lado del servidor y evitar la transmisión del saltedSecret generado desde el lado del cliente.

En general, el cifrado de la capa de transporte, como TLS, se considera un control suficiente contra los ataques MITM, por lo que quizás deba sopesar si la implementación del hashing del lado del cliente en realidad mitiga las amenazas significativas mejor que simplemente confiar en TLS. Por ejemplo, si TLS está comprometido, es probable que un MITM pueda inyectar JavaScript para capturar la contraseña de cualquier manera.

    
respondido por el thexacre 02.04.2015 - 02:43
fuente

Lea otras preguntas en las etiquetas

Informe Snort: más de 1000 alertas en 1 minuto desde el puerto 5060 Configurando un laboratorio de seguridad, buscando una pequeña guía [duplicar]