¿Cuál es la mejor manera de asegurar el inicio de sesión en un sitio web sin SSL o claves previamente compartidas?

Desea que el servidor de destino pueda acceder al nombre de usuario y la contraseña, y no al atacante sniffer. Por lo tanto, el servidor de destino debe poder hacer algo que el atacante no puede hacer. Dado que el atacante puede comprar el mismo tipo de PC que el servidor, esa potencia adicional debe ser algo que el servidor sepa, pero no el atacante.

Hola, hay hay dichos datos: ¡la contraseña! Ese es el punto, ¿no? Realmente es una clave precompartida entre el cliente y el servidor.

Las contraseñas son bastante malas, en lo que respecta a las claves, debido a las limitaciones de los cerebros humanos. Aún así, uno puede trabajar con eso. Los mejores protocolos para eso son Cambio de clave autenticado por contraseña : pueden escalar una clave compartida de baja entropía (la contraseña) en una clave compartida de alta entropía, con la que puedes hacer todo lo delicioso de la criptografía simétrica, que mantendrá a los tiburones a raya. Y los protocolos PAKE pueden hacer eso mientras resisten los ataques de diccionario offline (la palabra importante aquí es "offline").

La mala noticia es que los protocolos PAKE y, más generalmente, cualquier protocolo de autenticación que pueda vincularse posteriormente con datos intercambiados para que la autenticación realmente resista al atacante activo, son difíciles de acertar. El protocolo más simple pero seguro es el SSL con SRP (para eso hay un RFC ). La buena noticia es que SSL + SRP proporciona autenticación mutua basada en contraseña entre el cliente y el servidor utilizando sin certificado alguno (y cuando las personas dicen que no quieren usar SSL, lo que generalmente quieren decir es que no quiero meterse en los certificados X.509 y el friggin 'PKI market).

Desafortunadamente, el soporte de SSL + SRP no está muy extendido ( GnuTLS es una biblioteca de código abierto que conoce el SRP).

Si usa hash del lado del cliente, se convertirá en la contraseña real del sitio y no habrá logrado nada.

La mejor manera es usar SSL . El mecanismo existe por una razón. Los esquemas alternativos tienden a ser inseguros o increíblemente complejos.

Dijiste que querías hacerlo sin usar SSL, pero no dabas razones o razones para ello. No explicaste la situación en la que te encuentras o lo que justificaría evitar el SSL. En consecuencia, incluso si quisiéramos proporcionarle algunas sugerencias alternativas, sería imposible determinar si cumplen con sus requisitos.

Si todo lo que le interesa es autenticar al usuario en el servidor (y no le importa cifrar los datos posteriores), el Hash de Lamport sería fácil de implementar ya que ya hay bibliotecas de funciones hash implementadas en Javascript y PHP / ASP / ASP.net.

El hash de Lamport es un tipo de esquema de contraseña única que funciona de la siguiente manera (Alice es el usuario, Bob es el servidor):

Registro inicial

Al registrarse, Alice envía [n, hash ^ n (contraseña)] al servidor (donde hash ^ n es el resultado del hashing de la contraseña, luego el hashing del resultado, y luego el hashing del resultado, .. ., n veces). El servidor almacena [n, hash ^ n (contraseña)] en la base de datos.

Autenticación

1. Alice envía su ID (nombre de usuario) a Bob: "Alice"
2. Bob responde con "n"
3. Alice envía x = hash ^ {n-1} (contraseña) a Bob
4. Bob compara el hash (x) con el compendio almacenado en su base de datos
   • Si coinciden, la autenticación es exitosa y Bob reemplaza [n, hash ^ n (contraseña)] con [n-1, x = hash ^ {n-1} (contraseña)]
   • De lo contrario, la autenticación falla y Bob retiene lo que está en la base de datos

Consideraciones prácticas

• Lo más probable es que desees usar un salt con la contraseña (Bob puede enviar el salt en # 2)
• Una vez que n sea lo suficientemente pequeño, Alice tendrá que cambiar su contraseña (o simplemente pueden cambiar la sal), y tendrá que reenviar [n, hash ^ n (salt + contraseña)] a Bob
• Elija n lo suficientemente grande como para que la reinscripción no sea demasiado frecuente
• Dado que esta es solo una forma de autenticación (el usuario se autentica en el servidor, pero el servidor no se autentica en el usuario), es posible el uso de intermediarios.

Si el Hash de Lamport no cumple con sus requisitos (por ejemplo, necesita autenticación mutua), SRP es probablemente su mejor opción, pero en el momento en que lo haya implementado en Javascript y PHP / ASP / ASP.net, podría haber alquilado un servidor que admita SSL, que es claramente la mejor opción desde el principio.

La respuesta es TLS (ni siquiera SSL) sin AES como algoritmo de cifrado, ya que existe un problema conocido con la combinación de TLS, AES y WebSockets, por ejemplo. Todo lo demás (como cifrar la contraseña en el cliente usando javascript) es inseguro. Por supuesto, no se puede leer directamente usando wireshark pero el javascript puede provenir de un hombre en el medio. ¿Así que intenta convencer a tu escuela? para cambiar a los servidores TLS. Esta es la forma más fácil y no requerirá ningún cambio en el código de la aplicación.

Si puede ejecutar JavaScript en el cliente, puede configurar un intercambio de claves Diffie-Helman o un mecanismo de desafío / respuesta basado en el hash de la contraseña (¡no almacene texto plano en su sistema!) y usarlo para hacer una fantasía Proceso de autenticación en el que se devuelve una credencial cifrada para la autenticación.

Esos no detendrán los ataques MITM activos, pero evitarán que los atacantes pasivos detecten las contraseñas.

SSL no puede estar tan roto como las contraseñas de texto simple. Utilice SSL. Creo que Scheier tiene algo que decir sobre las personas que diseñan sus propios criptosistemas.

  

No me gusta SSL porque está roto.

Eso es un reclamo bastante dramático para desechar sin ninguna explicación ni referencias de apoyo. ¿Se refiere a todas las formas de SSL, incluido TLS o específicamente SSL v1-3?

Es mucho mejor que muchos otros intentos de solución al problema.

La única forma de establecer una comunicación segura es a través del cifrado, y para un cliente basado en navegador, si no está utilizando la funcionalidad incorporada de SSL, entonces está entregando el código para implementar el cifrado (ya sea Javascript, activex , java, flash ....) sobre una conexión no segura. Por lo tanto el código puede ser comprometido. No importa si utiliza rot13 o una clave de 4096 bits con un algoritmo PFS; si el código se entrega de forma insegura, es fácil modificar el código para capturar la contraseña.

Si crees que SSL está dañado, entonces arréglalo, es una forma mucho más rentable de pasar tu tiempo.

Lo primero que comprobaría es si el servidor admite la autenticación http con la autenticación de resumen. Es posible que pueda habilitarlo a través de php.

enlace

No es tan seguro como SSL, pero podría ser un simple truco para evitar que las personas de su clase pasen sus contraseñas. Use http auth para bloquear el área del sitio que necesita proteger. Verán todo lo que estás haciendo, pero no obtendrán la contraseña de autenticación http. (obtendrán cualquier otra contraseña dentro de la sesión)