¿Verifique que la contraseña esté en blanco con nonce cuando la contraseña ya esté en el servidor?

  

¿Tengo razón al decir que esto no funcionará si la contraseña no se almacena en texto sin formato en el servidor? No veo cómo el servidor podría verificar el hash si la contraseña ya está hash (con sal y pimienta) en el servidor.

Este esquema requiere que la contraseña se almacene en texto sin cifrar. Muy mal.

  

¿Se puede extender este esquema para que funcione de alguna manera con contraseñas hash?

Estoy seguro de que puede, pero no es necesario. El esquema al que hace referencia es el protocolo de autenticación de resumen de HTTP . Fue escrito en un día en el que se consideraba costoso implementar SSL en muchos sistemas. Digest authn proporcionó una forma de iniciar sesión a través de canales de texto simple sin exponer la contraseña. Ya no hay razón para hacer eso. SSL ahora es efectivamente libre.

En general, se considera que el riesgo de almacenar las contraseñas en el servidor es mayor que el beneficio de que el servidor no tenga su contraseña en la memoria por un corto período de tiempo (tiempo desde la recepción del mensaje de contraseña hasta que comience el hashing y la memoria de la contraseña de texto se puede borrar).

Hay algunas situaciones donde el hashing del lado del cliente puede tener sentido. Por ejemplo, LastPass implementa un mecanismo de autenticación único que involucra el hashing del cliente y del servidor. Lo hacen porque usan su contraseña como la base para crear su clave de cifrado y nunca quieren que el servidor conozca su clave de cifrado. Entonces, lo que hacen es:

1. Muchas rondas de PBKDF2 en el cliente para crear una clave de cifrado segura.
2. Una ronda de SHA-256 para convertir la clave de cifrado en lo que efectivamente es su contraseña.
3. Enviar contraseña al servidor. Tenga en cuenta que las propiedades de SHA-256 hacen que sea computacionalmente imposible revertir la contraseña a su clave de cifrado.
4. El servidor realiza el hashing estándar del lado del servidor utilizando PBKDF2 y salt.

Básicamente, el servidor LastPass realiza el almacenamiento de contraseñas estándar, pero lo que se obtiene como una "contraseña" es el resultado del hashing del lado del cliente.

Si está utilizando un canal seguro, es decir, TLS, no necesita hacer este tipo de trucos.

• Acerca de su primera pregunta, sí, tiene razón, este esquema requiere que el servidor tenga acceso a la contraseña en texto sin cifrar para poder reproducir H (nonce + cnonce + contraseña).
• Sobre tu segunda pregunta, no puedo pensar en una manera que no te abra para los ataques de repetición (pero no soy el mejor en este campo)
• No, agregar sales no complica las cosas más de lo que es mientras tiene solo el hash en el lado del servidor. (Si tiene la contraseña simple, que no tiene, en este escenario, calcular el hash con o sin el salt no es muy diferente).

  

¿Se puede extender este esquema para que funcione de alguna manera con contraseñas hash?

No este esquema. Debido a cómo funciona, debe tener la contraseña o algún equivalente específico (consulte enlace para detalles) para hacer algunos cálculos necesarios.

Por supuesto, con un enfoque ingenuo, podría modificar el esquema para que el hashing de la contraseña ya se hiciera en el cliente, de modo que se pueda utilizar una contraseña con hash en el servidor para la comparación. Pero en este caso, la contraseña original con hash se convierte esencialmente en la nueva contraseña que necesita proteger y la contraseña original no importa en absoluto.

La idea principal de una contraseña con hash es que tiene una operación irreversible para proteger la contraseña en la base de datos y que utilizará esta operación irreversible en la contraseña real primero cuando agregue el hash a la base de datos y luego cuando compare la contraseña ingresada Contraseña contra la entrada de la base de datos. Esto significa que debe proteger el transporte (es decir, usar TLS) o la base de datos (es decir, poner la contraseña y borrar la base de datos). Si necesita un esquema donde no puede proteger la base de datos ni el transporte, intente con la criptografía de clave pública.