Permitir que los usuarios retomen lo que dejaron ... sin iniciar sesión (¿es esta forma incorrecta?)

Question

Permitir que los usuarios retomen lo que dejaron ... sin iniciar sesión (¿es esta forma incorrecta?)

#1 de Eric G (5 votos)
#2 de monkeymagic (3 votos)
#3 de nvuono (0 votos)

3

Tengo una aplicación Grails en la que estoy trabajando y que permite a los usuarios completar un formulario de solicitud bastante largo. Uno de los requisitos que me han dado es NO requerir que los usuarios inicien sesión ni creen ningún tipo de cuenta. Cuando comienzan a llenar la aplicación, almaceno su ID de aplicación en la sesión para que pueda ser recordada de una página a otra. Después de una hora, la sesión expira. Si no terminaron la aplicación, les envío un correo electrónico agradeciéndoles por considerarnos.

Lo que debo hacer es dar a los usuarios la capacidad de continuar donde lo dejaron para que puedan finalizar la aplicación ... otra vez, sin una cuenta, sin una combinación de nombre de usuario / inicio de sesión.

Una forma en que pensé hacer esto fue crear una ID única (como adbce-13428-etace-etc ...) que se almacena en la base de datos y se asigna a su ID de aplicación. Luego les enviaré un enlace en el correo electrónico que dice "Si desea continuar llenando su solicitud, haga clic en el siguiente enlace: myapp.com/continue/{their_unique_id}". Cuando hacen clic en eso, busca la ID única en la base de datos, obtiene su ID de aplicación y vuelve a colocar la información en la sesión para que puedan finalizar la aplicación.

Mi pregunta es : ¿es esta forma incorrecta? ¿Es mal diseño? ¿Es malo para la seguridad? ¿Por qué?

defense cookies session-management

pregunta grantmcconnaughey 23.04.2014 - 22:06

fuente

3 respuestas

Lea otras preguntas en las etiquetas defense cookies session-management

mencionado en un blog por un "pirata informático": ¿debería importarme? ¿Por qué necesita cifrar una clave simétrica?

score 5 · Answer 1

Puede aprovechar el almacenamiento local, pero también corre el riesgo de exponerlo a una computadora multiusuario o pública, o la facilidad de uso si el usuario usa varias computadoras.

En su solución de correo electrónico, puede agregar un código especial / token / contraseña además de su identificador. Así que tienes el identificador (UUID) y luego un secreto. Todavía tiene una exposición si el correo electrónico está comprometido, pero si el UUID está comprometido por los registros, la captura de paquetes, etc., sin el acceso secreto no se puede otorgar a través del canal diseñado. Podría poner el secreto como otro parámetro en la URL, pero eso es un poco menos seguro ya que se expondrá donde sea que se registre la URL ya que está en el GET

por ejemplo.

Oye, vuelve a enlace ...... en la página, ingresa el siguiente código para continuar XXXX

Los datos de la aplicación y el secreto deben caducar y ser eliminados o no visibles desde la perspectiva del usuario después de un período de tiempo (los secretos tienden a ser menos secretos con el tiempo).

score 3 · Answer 2

El hecho de que sea perjudicial para la seguridad depende de si la información que están ingresando puede considerarse "confidencial".

¿Le importaría al solicitante si alguien más pudiera adivinar (aunque sea poco probable) su ID de sesión y tener acceso a cualquier información que ya haya ingresado? (¿Es importante la confidencialidad de los datos?)

¿Le importaría a la organización que recibe los datos del solicitante que la parte 1 podría haber sido completada por una persona y la parte 2, o la parte 3, etc., podría haber sido completada por otra persona o personas? (¿Es importante la integridad de los datos?)

Si un atacante logró averiguar el proceso que se está utilizando para lograr la funcionalidad de "guardar y reanudar más tarde" y fue capaz de recopilar todos los datos enviados, ¿sería malo para la reputación de la organización? ¿Su reputación sufrirá?

Si la respuesta a cualquiera de estas preguntas es sí, puede que no sea una buena idea. Como con la mayoría de las cosas en seguridad, todo se trata de los datos.

score 0 · Answer 3

Estoy de acuerdo con la respuesta y afirmación de monkeymagic de que "todo se trata de los datos" y definitivamente implementaría un token secreto como sugirió Eric G.

En un comentario, mencionó que la información de SSN se ingresa en algún momento, por lo que un paso adicional que puede implementar es ocultar cualquier información particularmente confidencial que se haya ingresado previamente cuando un usuario reanuda su aplicación. Quizás al reanudar una aplicación en curso, su SSN solo se mostrará como: XXX-XX-1234

Sabemos que ocultar el SSN mostrando solo los últimos 4 dígitos NO es una solución perfecta, pero incluso si alguien logró averiguar su esquema de generación de UUID y adivinar un montón de URL válidas, es probable que deseen revelar información confidencial como la completa Los SSN son MUCHO más altos que la probabilidad de que estén motivados para continuar con algunas solicitudes en curso y completarlas de manera fraudulenta.

Otra preocupación es si esta es una aplicación para algún proceso que los humanos tomarán para el próximo paso y tendrán la oportunidad de realizar alguna confirmación / verificación. Es un problema diferente que si el último paso es "Ingrese la cuenta bancaria número que desea que depositemos dinero en "