https URL con el parámetro 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 obtener los resultados de la simulación más tarde, pero sin forzarlos a crear una cuenta de inicio de sesión/contraseña.

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

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

Por último, recibirían un correo electrónico de esa manera:

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

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

Answer 1

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

Además, dependiendo de su servidor web, la URL completa puede registrarse en sus archivos de registro. Dependiendo de qué tan confidenciales 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á en el historial de usuario, permitiendo que otros usuarios de la misma máquina accedan a la URL.

Por último, y lo que hace que esto sea muy inseguro, la URL se envía en el encabezado Referer de todas las solicitudes de recursos, incluso recursos de terceros. Entonces, si usa 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

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

Answer 3

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

De todos modos, una forma de mitigar que un atacante reutilice el token de URL es asegurarse de que cada token solo se pueda usar una vez. Incluso podría establecer una cookie para que el usuario legítimo pueda continuar usando el enlace, pero después del primer acceso solo funcionará para alguien que tenga la cookie.

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

Answer 4

Usted sabe que si un pirata informático obtiene acceso a su base de datos, se puede dar libremente mucha información personal.

Después de eso, diría que esto no está mal como idea. No usaría MD5 o SHA1 ya que no son muy seguros para hash. Se pueden "descifrar" (sé que no es cifrado) con bastante facilidad.

De lo contrario, podría utilizar 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 tiene 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 no menos.

Answer 5

Bueno, el token es seguro cuando se pasa a través de SSL. El problema que vas a tener 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 una contraseña para el sitio. Es muy 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á comprometida, entrará en una misión cuya culpa es en realidad. Cuanto más seguro mejor, desde un punto de vista estrictamente CYA.

Answer 6

Por lo que entiendo de su idea, en teoría, alguien podría escribir una cadena aleatoria de 40 caracteres o un hash MD5 y obtener detalles de otra persona. Si bien esto puede ser altamente improbable, solo debe suceder una vez.

Una mejor solución podría ser enviar 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.

Answer 7

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

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

Answer 8

Yo 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 los datos. Los datos se almacenan en el DB usando alguna clave que se almacena en la cookie.
4. Cuando el usuario se va, envíeles un correo electrónico con un https: enlace
5. Cuando el usuario vuelve, el sitio descubre la cookie y puede presentar al usuario los datos anteriores.

Ahora, el usuario desea utilizar un navegador diferente en una máquina diferente. En este caso, ofrece un botón de "transferencia". Cuando el usuario haga clic en este botón, obtendrá un "token". Ella puede usar esta ficha en otra computadora para restablecer la cookie. De esta manera, el usuario decide qué tan segura quiere transferir el token.

Answer 9

Como lo es, sería una mala idea. Va a 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 arriesgados 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 la idea de la cookie.También debe encriptar la información de la cookie. 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 la verificación.

La frase clave podría ser almacenada en la cookie para el uso fácil pero hay que tener en cuenta que también la galleta puede ser robado = (.

mejor dejar que el cliente escriba la frase clave que proporciona, 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 pase por alto la cookie. o establecer

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