¿Los sitios que comprueban su contraseña mientras escribe pueden suponer un riesgo para la seguridad?

Los criptosistemas modernos generalmente no son susceptibles a ataques de texto plano conocido. En términos de algoritmos de cifrado, hay básicamente 3 algoritmos comúnmente utilizados en TLS:

1. AES
2. RC4
3. DES (en 3DES)

Se cree que los 3 de estos son resistentes a los ataques de texto plano conocido, y han sido bien estudiados para tales ataques.

Lo único que me gustaría preguntarme son los ataques de canal lateral. Hay (potencialmente) varios bits de información que se filtran sobre su contraseña, pero puedo pensar que todos requieren un atacante que sea capaz de observar su tráfico (por supuesto, también lo haría el ataque de texto simple conocido que preguntó). p>

1. Si la compresión TLS está habilitada (lo que realmente no debería estar habilitado, dado el ataque CRIME ) y un atacante puede adivinar correctamente todos los demás datos enviados en su solicitud (lo cual no es difícil si no hay cookies únicas), entonces es posible que puedan averiguar su contraseña enviando subcadenas y viendo cuáles se comprimen al la misma longitud que tu contraseña.

2. Ataques de tiempo. Dependiendo de la rapidez con la que el JavaScript envía las solicitudes al servidor después de escribir las pulsaciones de tecla y sus patrones de escritura, un atacante puede discernir (o al menos reducir) qué caracteres está escribiendo en función de los intervalos entre paquetes (lo que indica el intervalos entre pulsaciones de teclas). Este ataque se demostró contra SSH por Song et. al. en 2001, por lo que no es exactamente una novela, solo una novela para HTTPS. (HTTPS generalmente no es en tiempo real, pero lo que estás describiendo lo hace aproximadamente en tiempo real).

3. La longitud de la contraseña. El atacante podría medir la cantidad de paquetes enviados al servidor y sus tamaños, y hacer una buena estimación de la longitud a partir de la cantidad de caracteres escritos. Saber la longitud de una contraseña reduce la base en 1. Entonces, en lugar de tener que adivinar 11 ^ 5 contraseñas, el atacante solo tiene que adivinar 10 ^ 5 contraseñas para contraseñas numéricas.

En general, esto no es lo que me preocupa. Es mucho más probable que este sitio web sea vulnerable a XSS, inyección de SQL, vulnerabilidades de administración de sesión, etc., que si un atacante utilizara esta técnica de ida y vuelta para comprometer su cuenta.

Si nada más, es una API para verificar las contraseñas sin demora de tiempo . Tiene que ser: si hubieran tenido un retraso de tiempo después de cada suposición incorrecta, se anularía el punto de verificación en vivo de la contraseña. Si su contraseña es "contraseña", entonces el servidor debe verificar siete contraseñas incorrectas antes de llegar a la correcta, y no puede permitirse un retraso después de cada pulsación de tecla. Un usuario puede omitir esto cortando / pegando la contraseña de otro lugar, pero este no es el comportamiento que queremos fomentar.

Por razones similares, es casi seguro que esta API no bloquea a las personas después de repetidas suposiciones incorrectas . Incluso si lo hace, el umbral es probablemente inaceptablemente alto. Un cracker basado en malware funcionaría especialmente bien aquí: podría raspar el disco duro de un usuario en busca de contraseñas probables, luego emular cortar / pegar para que solo desperdicie una conjetura por contraseña completa en lugar de longitud - 1 conjeturas .

Las personas que implementan este tipo de verificador tienen buenas intenciones, pero el concepto subyacente es fundamentalmente defectuoso. Nadie debería estar haciéndolo. Solo te estás abriendo a ataques maliciosos, para no obtener una ganancia real de UX.

Tal vez sea una pregunta tonta, pero ¿está seguro de que no está recibiendo ✓ lo que significa que la contraseña que ha ingresado cumple con los requisitos mínimos de la política de contraseña del sitio? De tal manera que el código del lado del cliente dice "sí, esta es una contraseña válida y la aceptaré, aunque todavía no he validado la corrección". Cuando ingresa la contraseña como "password1234", ¿sigue siendo un ✓?

Puedo ver un problema grave aquí: puede intentar un cracking de fuerza bruta mientras el servidor realiza el trabajo pesado. En el caso de un servidor suficientemente poderoso, el atacante tiene una buena probabilidad de éxito con poco o ningún costo de computación (del lado del cliente). Si el servidor es demasiado débil, abre un canal agradable para un ataque de denegación de servicio.

La última vez que lo verifiqué, se consideró una buena práctica introducir un sueño pequeño (aleatorio) antes de devolver los resultados; comprobar la contraseña para cada carácter escrito parece funcionar hacia atrás a partir de esto.

No veo ninguna razón para que la contraseña incompleta se envíe al servidor. El cliente conoce las reglas de la contraseña (es decir, 8 caracteres, debe contener un número, etc.) y puede validarla y mostrar el estado. al usuario antes de enviar cualquier solicitud