Estoy estudiando el Mecanismo de Autenticación de Respuesta de Desafío Salado (SCRAM).
Según la descripción en enlace parece que el Cliente no tiene que saber la contraseña en Texto sin formato; saber la contraseña de Salted es suficiente para calcular la prueba del cliente.
Eso significaría que si logro obtener las contraseñas con sal de una base de datos, podría iniciar sesión sin tener que forzar las contraseñas.
¿Mi entendimiento de SCRAM es correcto a este respecto?
Descargo de responsabilidad : No soy un experto en criptografía, por lo que esta respuesta proviene de mi comprensión limitada del protocolo.
Veamos el protocolo
SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)
¿Quién sabe qué al principio?
La respuesta
Tiene razón en que solo se requiere el SaltedPassword para calcular todo, pero el problema es que nadie almacena ese SaltedPassword. Además, si simplemente desea personificar al cliente, solo necesita ClientKey para engañar al servidor.
La idea detrás de SCRAM - > ¿Un fallo?
El mecanismo de autenticación segura más ampliamente implementado y utilizado por Protocolos de aplicación de Internet es la transmisión de texto claro. contraseñas sobre un canal protegido por Transport Layer Security (TLS). Hay algunos problemas importantes de seguridad con ese mecanismo, que podría ser abordado por el uso de una respuesta de desafío Mecanismo de autenticación protegido por TLS.
Aún así, no parece explicar cómo protegerá la contraseña del servidor. Debe comprender que incluso si utiliza algún tipo de mecanismo de respuesta de desafío sofisticado para "nunca" enviar la contraseña a través del cable, que cuando ingresa la contraseña en la página del navegador, que recibe el servidor, el script en la página podría decidir registrar su contraseña incluso si le dice que no.
La principal ventaja, que veo, de un mecanismo de desafío-respuesta para los usuarios es que podrían reutilizar la misma contraseña en todas partes. Pero, como el usuario realmente no puede confiar en la página donde ingresa su contraseña, no puede reutilizar su contraseña.
Entonces, la próxima gran ventaja que podría pensar es que en un mecanismo de respuesta-desafío la contraseña no suele estar almacenada en el servidor. Por lo tanto, incluso si un atacante robó una copia del servidor, no puede intentar deshacer la contraseña. Nuevamente, es un gran error ya que el servidor tiene una copia de la contraseña almacenada, el salt y el recuento de iteraciones. Tiene todo lo que necesita para intentar descifrar su contraseña a través de un diccionario o un ataque de fuerza bruta.
En algún momento, tengo que preguntarme, ¿por qué no simplemente dar la contraseña al servidor? La única protección que agrega es que si se rompe el TLS (pero el atacante solo puede escuchar), el atacante todavía tiene que forzar su contraseña para obtener acceso.
Lea otras preguntas en las etiquetas authentication hash pbkdf2