security - name - https URL con el parámetro token: ¿qué tan seguro es?

meta name keywords

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.

Pensamos en enviarles un correo electrónico con un enlace, desde el cual pudieran 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.

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

Hola,
Obtenga los resultados nuevamente en https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

¿Qué piensa usted 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

¿Sabía que si un pirata informático accede 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, 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 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 2

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 3

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 4

Por lo que entiendo de tu idea, en teoría alguien podría escribir una cadena aleatoria de 40 caracteres o un hash MD5 y obtener más detalles. 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 5

Realmente no lo consideraría tan seguro como para una situación en la que haya 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.

Por cierto, no hay problemas con los parámetros en una solicitud https.

Answer 6

SSL protege 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ás contaminado. Pero el usuario también tiene problemas más grandes.

Answer 7

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, lo que permitirá que otros usuarios de la misma máquina accedan a la URL.

Finalmente, y lo que hace que esto sea muy inseguro, la URL se envía en el encabezado Referer de todas las solicitudes de cualquier recurso, 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 8

Tal como 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 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 puede almacenarse en la cookie para facilitar el uso, pero tenga en cuenta que también se puede robar la cookie = (.

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

O bien, 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 omita la cookie. Entonces la cookie se puede transferir o establecer.

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

Answer 9

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

Ahora, el usuario quiere usar 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.