https URL con parámetro de token: ¿qué tan seguro es?

Question

En nuestro sitio, proporcionamos a los usuarios una simulación basada en su información privada (proporcionada a través de un formulario). Nos gustaría permitirles volver a sus resultados de simulación más tarde, pero sin obligarlos a crear una cuenta de inicio de sesión / contraseña.

Hemos pensado enviarles un correo electrónico con un enlace, desde el cual podrían recuperar sus resultados. Pero, naturalmente, tenemos que asegurar esta URL, porque los datos privados están en juego.

Entonces, tenemos la intención de pasar un token (como una combinación de letras y dígitos de 40 caracteres, o un Hash MD5) en la URL y usar SSL.

Finalmente, recibirían un correo electrónico como ese:

  

Hola,
  Recupere sus resultados en    https://www.example.com/load_simulation?token=uZVTLBCWcx.

¿Qué opinas al respecto? ¿Es lo suficientemente seguro? ¿Qué me aconsejarías para la generación de tokens? ¿Qué pasa con pasar parámetros de URL en una solicitud https?

Answer 1

SSL protegerá los parámetros de consulta en tránsito; sin embargo, el correo electrónico en sí no es seguro, y el correo electrónico podría rebotar en cualquier número de servidores antes de llegar a su destino.

También, dependiendo de su servidor web, la URL completa podría registrarse en sus archivos de registro. Dependiendo de cuán sensibles sean los datos, es posible que no desee que su personal de TI tenga acceso a todos los tokens.

Además, la URL con la cadena de consulta se guardaría en el historial de su usuario, permitiendo que otros usuarios de la misma máquina accedan a la URL.

Finalmente, y lo que lo hace muy inseguro es que la URL se envía en el encabezado Referer de todas las solicitudes de cualquier recurso, incluso recursos de terceros. Entonces, si está utilizando Google Analytics, por ejemplo, le enviará a Google el token de URL y todo a ellos.

En mi opinión, esta es una mala idea.

Answer 2

Usaría una cookie para eso. El flujo de trabajo debería ser así:

1. El usuario llega a su sitio por primera vez.
2. El sitio establece una cookie
3. El usuario ingresa datos. Los datos se almacenan en la base de datos utilizando alguna clave que se almacena en la cookie.
4. Cuando el usuario se va, le envía un correo electrónico con un enlace https:
5. Cuando el usuario regresa, el sitio descubre la cookie y puede presentarle al usuario los datos antiguos.

Ahora, el usuario quiere usar un navegador diferente en una máquina diferente. En este caso, ofrezca una "transferencia". botón. Cuando el usuario hace clic en este botón, obtendrá un "token". Puede usar este token en otra computadora para restablecer la cookie. De esta manera, el usuario decide qué tan seguro quiere transferir el token.

Answer 3

SSL asegura el contenido de los datos en tránsito, pero no estoy seguro acerca de la URL.

Independientemente, una forma de mitigar a un atacante que reutiliza ese token de URL es asegurarse de que cada token solo se pueda usar una vez. Incluso podría configurar una cookie para que el usuario legítimo pueda continuar utilizando el enlace, pero después del primer acceso solo funcionará para alguien con la cookie.

Si el correo electrónico del usuario se ve comprometido y un atacante obtiene el enlace primero, bueno, estás alojado. Pero el usuario también tiene mayores problemas.

Answer 4

El correo electrónico es inherentemente inseguro. Si alguien puede hacer clic en ese enlace y acceder a los datos, en realidad no lo está protegiendo.

Answer 5

Bueno, el token es seguro cuando se pasa a través de SSL. El problema que tendrá es que está disponible para las personas (para quienes no está destinado) al poder ver la URL.

Si se trata de información privada como SSN, no creo que envíe una URL por correo electrónico. Prefiero que creen un nombre de usuario y contraseña para el sitio. Es demasiado fácil comprometer un correo electrónico con ese tipo de información en juego para usted y para ellos. Si la cuenta de alguien está comprimida, entrará en duda de quién es la culpa. Cuanto más seguro, mejor desde un punto de vista estrictamente CYA.

Answer 6

Realmente no consideraría eso lo suficientemente seguro para una situación en la que hay serios problemas de privacidad. El hecho de que esté enviando la URL en un correo electrónico (presumiblemente texto sin formato) es, con mucho, el enlace más débil. Después de eso, existe el riesgo de ataques de fuerza bruta en los tokens, que (sin la estructura de un mecanismo de autenticación real) es probable que sean más vulnerables que un nombre de usuario y una configuración de contraseña bien construidos.

No hay problemas con los parámetros en una solicitud https, por cierto.

Answer 7

Tal como está, sería una mala idea. Escarificará la seguridad con un uso fácil. Como se dijo antes, SSL solo protegerá la transferencia de información entre el servidor y el navegador del cliente y solo evitará el ataque del intermediario. Los correos electrónicos son muy riesgosos e inseguros.

Lo mejor sería una autenticación de nombre de usuario y contraseña para acceder a la información.

Me gusta más o menos la idea de las cookies. También debe cifrar la información de las cookies. También debe generar el token con sal y frase clave más $ _SERVER ['HTTP_USER_AGENT'] para limitar la probabilidad de un ataque. Almacene tanta información no sensible sobre el cliente en la cookie para el uso de verificación.

La frase clave podría almacenarse en la cookie para facilitar su uso, pero tenga en cuenta que también se puede robar la cookie = (.

Mejor deje que el cliente escriba la frase clave que proporcionó, que también se almacena en la base de datos junto con sus datos.

O, la clave se puede usar en caso de que la persona use una máquina diferente que difiera en los parámetros $ _SERVER ['HTTP_USER_AGENT'] o simplemente pierda la cookie. Por lo tanto, la cookie se puede transferir o configurar.

También asegúrese de que los datos confidenciales estén encriptados en la base de datos. Nunca se sabe;)

Answer 8

¿Sabe que si algún hacker obtiene acceso a su base de datos, se puede dar mucha información personal gratuitamente?

Después de eso, diría que esto no es una mala idea. No usaría MD5 o SHA1 ya que no son muy seguros para el hash. Pueden ser "descifrados" (Sé que no es encriptación) con bastante facilidad.

De lo contrario, tal vez usaría una segunda información que no se enviaría por correo electrónico como una contraseña. La razón es bastante simple, si alguien obtiene acceso al correo electrónico del usuario (bastante fácil con hotmail si no mata su sesión) tendrá acceso a cualquier información que el usuario haya enviado.

Tenga en cuenta que el HTTPS protegerá y cifrará los datos enviados desde su sitio al usuario final. Nada más, tómalo como un tunel seguro. Nada más y nada menos.

Answer 9

Por lo que entiendo de su idea, en teoría alguien podría escribir una cadena aleatoria de 40 caracteres o hash MD5 y obtener detalles de alguien más. Si bien esto puede ser muy poco probable, solo tiene que suceder una vez.

Una mejor solución podría ser enviarle al usuario un token y luego pedirle que ingrese algunos de los detalles, como su nombre, código postal, ssn o una combinación de estos.