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

89

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 en enviarles un correo electrónico con un enlace, desde el que pudieran recuperar sus resultados. Pero, naturalmente, tenemos que proteger esta URL, porque están en juego datos privados.

Por lo tanto, 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 así:

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

¿Qué piensa usted al respecto? ¿Es lo suficientemente seguro? ¿Qué me aconsejarías para la generación simbólica? ¿Qué hay de pasar parámetros de URL en una solicitud https?

Flackou
fuente

Respuestas:

97

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 puede rebotar en cualquier número 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 la confidencialidad de los datos, es posible que no desee que el 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, lo que permitiría a otros usuarios de la misma máquina acceder a la URL.

Finalmente, y lo que hace que esto sea 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.

JoshBerke
fuente
1
No había pensado en el problema del HTTP-referer, pero el enlace de la URL redirigiría a la página de resultados, no sería una página adecuada (sin Google Analytics u otro script de terceros).
Flackou
5
¿No eliminan la mayoría de los navegadores la referencia al pasar de HTTPS a HTTP?
Kevin Mark
2
Esto es similar al enlace de activación de usuario (o restablecimiento de contraseña), ¿verdad? Entonces, ¿cómo debería manejarse ese caso? Muchos sitios web envían URL de restablecimiento al correo electrónico, POST no es una opción, ya que debería poder hacer clic en él. Gracias.
pinkpanther
3
¿entonces, cuál es la solución?
RT
1
¿Qué pasa si el token en la URL no es el mismo que el token utilizado para las solicitudes de API y solo dura una hora, entonces cuál sería el daño?
user1709076
13

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 un botón de "transferencia". 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.

Aaron Digulla
fuente
4

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

Independientemente, una forma de mitigar que un atacante reutilice ese token de URL es asegurarse de que cada token solo se pueda usar una vez. Incluso puede configurar una cookie para que el usuario legítimo pueda continuar usando 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á condenado. Pero el usuario también tiene mayores problemas.

Eli
fuente
11
La conexión SSL está protegida antes de que se transmita la URL.
David
1

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

Jason Punyon
fuente
Exacto, pero muchos muchos sitios no se preocupan por eso y envían inicio de sesión / contraseñas por correo. Pero no es una razón para imitarlos ...
Flackou
No estoy de acuerdo con ninguna razón para imitarlos, pero generalmente le dicen que cambie la contraseña después de iniciar sesión por primera vez.
Jason Punyon
1

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 (aquellas a las que no está destinado) al poder ver la URL.

Si es información privada como SSN, no creo que envíe una URL por correo electrónico. Preferiría que crearan un nombre de usuario y una 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á comprometida, se cuestionará de quién es realmente la culpa. Cuanto más seguro, mejor es desde un punto de vista estrictamente CYA.

kemiller2002
fuente
1
Tienes razón: la URL permanecería en el historial del navegador, por ejemplo
Flackou
0

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

Por cierto, no hay ningún problema con los parámetros en una solicitud https.

caos
fuente
Tienes razón sobre el riesgo de ataques de fuerza bruta. No veo cómo podríamos prevenir a los bots de este tipo de ataque. Prohibir las IP "insistiendo" no sería una protección suficiente. ¿Tiene ideas sobre el tema?
Flackou
En realidad, con el tipo de espacio de claves del que estamos hablando, poner if (this_ip_number_has_requested_an_invalid_token_today ()) sleep (5); en su script load_simulation sería una protección perfectamente suficiente. (La limitación de velocidad es una de esas características de los buenos mecanismos de autenticación.)
chaos
Gracias por tu respuesta. Pero pensé que un mismo bot podría tomar fácilmente diferentes direcciones IP, lo que hacía que el límite de velocidad de IP no fuera suficiente. ¿Me equivoco?
Flackou
Todo lo que los consigue es un intento sin demora por IP. El espacio de direcciones IP no está disponible con tanta facilidad que eso es útil.
caos
0

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 galletas. También debe cifrar la información de las cookies. También debe generar el token con salt 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 su uso de verificación.

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

Es mejor dejar 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 pierda la cookie. Entonces 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 sabes ;)


fuente
-1

¿Es consciente de que si algún pirata informático obtiene acceso a su base de datos, se le puede dar gratuitamente mucha información personal?

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. 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 obtiene acceso al correo electrónico del usuario (bastante fácil con Hotmail si no cancela su sesión), tendrá acceso a cualquier información que el usuario haya enviado.

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

Erick
fuente
¿Cómo se descifra exactamente un hash SHA1 salado en cualquier sentido de la palabra?
Eli
"¿Es consciente de que si algún pirata informático tiene acceso a su base de datos, se le puede dar gratuitamente mucha información personal?" Sí, pero ¿no es un problema para todos los sitios web?
Flackou
@Flackou sí, pero si obtiene acceso a la base de datos de PayPal, no encontrará información de la tarjeta de crédito claramente guardada, todo está cifrado. @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
Erick
-1

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 los detalles de otra persona. Si bien esto puede ser muy poco probable, 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.

Richard Slater
fuente
5
SSN? ¿En serio? De todos modos, le sugiero que haga los cálculos sobre cuántas cadenas aleatorias de 40 caracteres hay. Es más que "muy poco probable"
Eli
Tiene razón, probablemente deberíamos agregar otro parámetro en la URL, como el correo electrónico (incluso si a..z + A..Z + 0..9 = 62 caracteres, y 62 ^ 40 es un número bastante grande).
Flackou
Chicos, 62 ^ 40 es considerablemente más que la cantidad de átomos en el universo. Es literalmente imposible de adivinar.
Eli
1
Me sorprende la cantidad de personas que no pueden comprender la escala de estos números. Si estuviera adivinando un MILLÓN de tokens por segundo, es mucho más probable que el sol se queme antes de recibir un golpe
Eli
4
Richard, parece que estás señalando lo que generalmente se llama la paradoja del cumpleaños ... no es solo la cantidad de combinaciones posibles lo que importa, sino cuántas de ellas se usan. Bueno, en este caso, debe usar aproximadamente 2 ^ 119 de las 62 ^ 40 combinaciones antes de que la probabilidad sea significativa.
erickson