¿Pin + guid en la URL segura para una aplicación web?

El uso del GUID como identificador único para el usuario en lugar de la dirección de correo electrónico tiene ventajas contra los atacantes de baja potencia . La URL con GUID se ha enviado por correo electrónico, por lo que no puede considerarse realmente secreta. Los atacantes motivados espiarán las líneas de la red y verán ese correo electrónico. Sin embargo, los aficionados o los robots de ataque automatizados, aunque no pueden leer los correos electrónicos de otras personas, pueden "adivinar" las direcciones de correo electrónico, pero no el GUID aleatorio.

El GUID tiene, por lo tanto, cualquier relación con la seguridad solo en la medida en que es impredecible, y entonces solo traerá algo bueno contra los atacantes que no son muy poderosos. Usar el GUID no daña , pero no crea que realmente agrega mucha protección. Es posible que desee asegurarse de que el GUID se genere con el algoritmo de la versión 4 , es decir, 122 bits de un fuerte PRNG: aunque el GUID apunta a singularidad , usted quiere imprevisibilidad , que es otra bestia; GUID versión 4 asegura tanto.

Teniendo en cuenta que el GUID no es (realmente) secreto, su sistema puede ser descrito como tal: hay una contraseña de registro de una sola vez, que es un PIN de cuatro dígitos. Después del registro, se utiliza una contraseña normal elegida por el usuario.

El problema principal es que el PIN de cuatro dígitos es demasiado fácil de adivinar: un atacante solo tiene, en promedio, que probar 5000 de ellos antes de golpear el correcto. Puede mitigar este problema desactivando el código PIN después de, por ejemplo, tres intentos incorrectos para un GUID determinado; ese es el modelo de tarjetas inteligentes , con su servidor como la tarjeta. Sin embargo, esto solo frustrará a los atacantes que hacen una fuerza bruta en línea .

Desafortunadamente, ocasionalmente, algunos atacantes obtienen un vistazo en algunas partes de la base de datos del servidor. Este es un resultado frecuente de los ataques de inyección de SQL, por ejemplo. Los discos duros viejos desechados también son una fuente clásica de este tipo de fugas. Esta es la razón por la que piensa almacenar no las contraseñas de los códigos PIN, sino solo las versiones con hash.

Pero hash de contraseña, incluso si se realizó correctamente , solo ralentiza los atacantes. Si el recuento de iteraciones es tan alto que toma diez segundos completo para que su servidor verifique un código PIN (y diez segundos son mucho tiempo para un cliente en espera), y el atacante "solo" se necesitan 50000 segundos de cómputo, con el mismo hardware, para "probar" 5000 códigos PIN posibles. Dado que el atacante lanzará un par de PC multi-core, probablemente se caiga dentro de una hora o dos. Eso no es mucho.

Aconsejo usar un código PIN más largo, digamos 8 dígitos.

Para resumir: su GUID no es "lo suficientemente secreto" para tolerar un PIN de cuatro dígitos, incluso para una página de registro de una sola vez. Es interesante usar un GUID en lugar de la dirección de correo electrónico y desea que sea lo más discreto posible (use el GUID "v4"), pero aún así, cuatro dígitos no son suficientes para un PIN cuando El sistema de verificación no es una tarjeta inteligente resistente a la manipulación. Utilice ocho dígitos (o más). Dado que el usuario escribirá el código PIN solo una vez, puede tolerar una secuencia bastante larga (Microsoft podría hacer que los usuarios escriban claves de activación de 25 letras, por lo que no creo que 8 dígitos para el registro sean demasiado para pedir). / p>     

El PIN es muy débil contra la fuerza bruta si un correo electrónico está comprometido, sin embargo, esto podría contrarrestarse parcialmente simplemente poniendo un bloqueo después de, por ejemplo, 3 intentos. Esto le da a un atacante una posibilidad de 1 en 3,333 de irrumpir. Todavía no es muy bueno, pero podría ser suficiente dependiendo del nivel de seguridad que necesite. También auditaría la frecuencia con que se bloquean y si empiezas a verlo bloquear mucho, lo cambiaría porque mostraría que alguien te está atacando.

Si de todos modos hay una contraseña temporal más larga, eso sería mucho más preferible, pero el bloqueo es un paso mínimo que podría usarse para ayudar a que el sistema sea mucho más seguro de lo que es actualmente. (Esto supone que los GUID también se generan de una manera impredecible. Si los GUID son predecibles, entonces el bloqueo no es suficiente, ya que se podrían realizar ataques contra una gran cantidad de GUID y atacar a más o menos 3000 para obtener un éxito es viable a menos que los GUID no se puede adivinar.)

1. Encuentro un número de 4 pines un poco corto cuando puedes usar una cadena generada al azar que sería más difícil de adivinar. Aunque una guía de 40 caracteres debería estar bien (asegúrese de que se haya generado correctamente y no sea previsible)
2. El GUID de 40 caracteres parece lo suficientemente largo
3. El aplastamiento y el salado de algo que solo puede ser un número entre 0000 y 9999 es un poco excesivo, ya que tomaría unos minutos generar todas las posibilidades, incluso con el salado adecuado.
4. Se ve bien, asegúrate de usar PBKDF2, bcrypt o scrypt para saltear y almacenar las contraseñas
5. Se ve bien

Lo único que puedes hacer para fortalecer esto es agregar la autenticación de dos factores. La autenticación de dos factores también se puede utilizar junto con la configuración de la contraseña inicial.

Debes dar un paso atrás y pensar en el contexto.

"¿Esto es lo suficientemente seguro?" Es una pregunta inútil.

"¿Es esto lo suficientemente seguro para un banco en el que los clientes pueden salvar vidas?" Es una buena pregunta.

¿Qué estás protegiendo con este sistema? ¿Qué tipo de equilibrio quieres lograr entre usabilidad y seguridad? Si este es un sistema de alta seguridad, entonces es obligatorio que los usuarios realicen un seguimiento de un PIN de diez dígitos. Si está protegiendo cuentas de bajo valor, entonces 4 dígitos probablemente estén bien.

Usted describe el pin de 4 dígitos como no único. Realmente no debería preocuparse por la singularidad, debería preocuparse por la previsibilidad y la fuerza bruta. Usar un generador de números aleatorios fuerte ayudará con la previsibilidad, usar un PIN más largo y tener bloqueos ayudará con los ataques de fuerza bruta.