¿Por qué la autenticación de contraseña requiere enviar la contraseña?

(Pregunta auto respondida ...)

Creo que esto se debe a que, por lo tanto, no se puede saltear y hash la contraseña en el servidor.

La salting de aviso aún es necesaria aquí porque si la contraseña del lado del servidor es robada, puede usarse para iniciar sesión incluso en el escenario de desafío-respuesta.

El motivo de las contraseñas enviadas en texto simple o en hash es principalmente histórico. En los viejos tiempos, cuando usábamos terminales simples sobre líneas seriales (70 a 80), solo eran posibles las soluciones de texto simple. Bueno, una contraseña de tiempo como S / Key también existía pero necesitabas la lista en papel contigo ...

Luego vino la era de PC, Windows y Lan Manager . Los miembros de Microsoft sabían que las redes Ethernet eran demasiado fáciles de espiar, por lo que decidieron intercambiar solo desafíos. La contraparte fue que fue necesario para almacenar la contraseña en forma invertible en el servidor.

El uso de crypto se hizo más popular con SSL, y muchos protocolos se adaptaron para usar canales encriptados (HTTP - > HTTPS por ejemplo). Y los administradores volvieron a descubrir los beneficios de solo almacenar hash en sus servidores: si la base de datos de contraseñas está comprometida, tiene mucho tiempo para cambiar las contraseñas.

Esa es la razón por la que las mejores prácticas son hoy en día para intercambiar contraseñas a través de canales encriptados y almacenar hashes con sal en los servidores, y por qué otras prácticas han existido ...

El motivo principal puede ser que, sea lo que sea que haga en el lado del cliente, puede evitarse fácilmente si no está utilizando una conexión HTTPS cifrada. El JavaScript puede ser modificado o eliminado completamente por un atacante ManInTheMiddle.

Entonces, en lo único en lo que puede confiar es en la conexión HTTPS / SSL cifrada. Si no tiene la conexión encriptada, todas las acciones del lado del cliente son bastante inútiles, si sí tiene una conexión HTTPS, las acciones del lado del cliente hacen poco para mejorar la seguridad.

Esto se aplica normalmente a los sitios web, es otro caso cuando el usuario instala un software cliente en su computadora. Con un software cliente instalado, no es necesario intercambiar código (JavaScript).

Tienes algunos problemas allí.

El servidor debe tener su contraseña para validar el hash que le envía. Si bien las cuentas SSH están configuradas localmente en el sistema antes del acceso remoto, su aplicación web común tendrá un formulario de registro y, en este caso, deberá enviar la contraseña en texto sin formato, lo que anulará el propósito de la autenticación resumida sugerida.
Lo mismo se aplica a la edición de contraseñas.

El segundo problema es que, si utiliza un método de transporte no seguro, aún puedo MITM e inyectar cualquier javascript que me guste en la página web, obteniendo su nombre de usuario, contraseña y todo lo demás.

MITM es un vector de ataque bien entendido, y ya tiene una solución: TLS.
De esta manera, toda la página se cifrará y se firmará, por lo que un eventual atacante no podrá ver ni editar nada, protegerá toda la secuencia de datos y hará que la autenticación de resumen sea redundante.

  

¿Por qué los sistemas que realizan autenticación de contraseña realmente envían el   contraseña por el cable? ¿Por qué no hacer que el servidor emita un   desafío ...

Déjame revertir la pregunta. ¿Qué obtendría si no enviara la contraseña por el cable? La respuesta a menudo no será nada.

El lugar principal donde usamos la contraseña es en Internet. Cuando visita una página web, esta página está controlada por el servidor y, por lo tanto, puede considerarla una extensión del servidor. Si el servidor está comprometido o es malo, tan pronto como escribe la contraseña en la página, puede considerar que está comprometido y esta contraseña debe cambiarse.

En su pregunta, parece preocuparse por el ataque MitM, pero solo considere el MitM que puede adjuntarse cuando envía el formulario y no cuando recibe la página, pero ambos son tan mortales. No importa si su contraseña no es "supuesta" para ser enviada o no, tan pronto como se escribe es lo mismo.

Entonces, ¿es totalmente inútil usar la autenticación de desafío-respuesta en una página web?

Si usas TLS, diría que sí. Recuerde que el cliente es solo una extensión del servidor.

Si no usa TLS, puede ayudar contra el espionaje pasivo, pero sigue siendo inútil contra MitM activo; Donde puedes modificar el contenido de la página. El hecho de que MitM activo sea mucho más difícil de lograr que las escuchas pasivas fue una razón que motivó la creación de dicho esquema. Consulte autenticación de resumen .

  

¿Por qué es diferente SSH?

Porque el servidor no controla al cliente. El cliente está completamente separado del servidor. Esto significa que cuando escribí mi contraseña secreta en el cliente, incluso si respondo a un desafío de un servidor malvado, mi contraseña secreta sigue siendo segura.

Es lo mismo con tu tarjeta de crédito. El chip inteligente en su tarjeta de crédito contiene una clave secreta que se utiliza para responder a un desafío-respuesta cada vez que realiza una compra. Esta clave secreta está protegida incluso si realiza una compra desde un terminal malvado.

Nota: Una ventaja del mecanismo de desafío-respuesta también es que le permite al usuario reutilizar la misma contraseña con varios servidores. Este punto es necesario para la tarjeta de crédito, por ejemplo, ya que usarán muchos terminales (servidores) y solo tendrán una contraseña.

El mecanismo de respuesta-desafío solo funciona cuando el servidor no controla al cliente.

Esto significa que si quisiéramos usar la autenticación de desafío-respuesta para la página web, tendríamos que implementarla en el nivel del navegador y no en el nivel de la página web. Si esa sería una buena idea o no es una pregunta completamente diferente.

  

Creo que esto se debe a que no se puede saltear la contraseña   el lado del servidor.

Es cierto que si utiliza el cifrado simétrico, no podrá proteger la contraseña correctamente en el servidor, ya que la necesita para verificar la respuesta del desafío. Es por eso que usa el cifrado asimétrico para el esquema de desafío-respuesta. Por ejemplo, tanto SSH como su tarjeta de crédito están utilizando el cifrado asimétrico. Con el cifrado asimétrico, puede almacenar la clave pública en el servidor y el usuario puede mantener su clave privada ... privada.