¿Cómo evitaría que alguien le vendiera su cookie persistente a alguien que no es miembro de la institución y quiere acceder?

21

La mayoría de nuestros editores venden suscripciones a instituciones y las personas obtienen acceso al ser identificadas como parte de la institución. La autenticación de esta institución ocurre con los rangos de IP o Shibboleth, pero no todas las instituciones son compatibles con Shibboleth u otro SAML, y los rangos de IP no ayudan sin VPN o servidor proxy. Por lo tanto, los editores quieren que diseñemos un esquema mediante el cual un usuario obtenga acceso a corto plazo a su participación institucional (es decir, al contenido suscrito por su institución) mientras está fuera del rango de propiedad intelectual de la institución (por ejemplo, en casa o viajando). .) La solución debe ser lo más simple posible para el usuario, no debe requerir que descargue nada y debería funcionar bien para los usuarios que vienen de teléfonos móviles o de sus computadoras portátiles. El proceso podría requerir que los usuarios inicien este acceso mientras se encuentren dentro del rango de IP, pero lo ideal es que puedan iniciar su acceso de 30 días incluso si están lejos de la institución y se olvidaron de configurarlo.

En particular, indique cómo afirmará el usuario que es un miembro (profesorado, estudiante, empleado, lo que sea) de la institución que reclama. Recuerde que la institución no tiene un servidor de autenticación y no instalará uno. Además, el usuario no instalará una aplicación en su computadora. La solución completa implicará invariablemente una cookie persistente en algún momento. ¿Cómo evitaría que alguien le vendiera su cookie persistente a alguien que no es miembro de una institución y quiere acceder?

    
pregunta Dimitris 03.05.2017 - 14:00
fuente

11 respuestas

67

¿Puede evitar que alguien venda su contraseña para obtener un acceso similar? ¿Crees que necesitas? Es prácticamente equivalente.

¿Necesita hacer esto?

Por mi experiencia al estar dentro / fuera de instituciones académicas con acceso a revistas, siempre hay cierta cantidad de recursos para compartir como un favor (por ejemplo, "hey, ¿podría enviarme un PDF de este documento?"). Nunca podrá detener eso, porque un usuario legítimo puede acceder a él en forma manual en una máquina correcta. Sin embargo, personalmente nunca he presenciado a estudiantes / personal tratando de ganar dinero con esto.

Supervisión

Incluso si quisieran ganar dinero de esta manera, entonces no creo que compartir las cookies sea la mejor manera, ¡ciertamente no es la forma en que lo haría! Las protecciones que podría agregar al sistema de cookies (por ejemplo, tomar las huellas digitales del navegador del usuario y verificar que se mantenga igual, etc.) no se aplicarán a otros métodos.

En cambio (si esto es realmente un problema), una solución razonable y robusta es monitorear los patrones de uso del usuario. Si están descargando 100x los recursos de cualquier otra persona, o si obtienen recursos constantemente durante 250 horas seguidas (los humanos más largos pueden sobrevivir sin dormir), entonces probablemente haya varios usuarios o un sistema automatizado en funcionamiento.

Sin embargo, esta solución de monitoreo no debe incluirse desde el principio, se puede agregar más adelante, y hasta que tenga pruebas de que en realidad es un problema, creo que debería ser bastante muy abajo en tu lista de cosas que hacer.

    
respondido por el cloudfeet 03.05.2017 - 14:27
fuente
45

No lo haces.

Esta pregunta es básicamente una variante de "¿Cómo hago DRM y lo hago funcionar?" y la respuesta es la misma.

No estoy seguro de por qué "vender una cookie persistente" parece ser tu principal amenaza. Normalmente, los usuarios simplemente reenviarán sus publicaciones a SciHub.

    
respondido por el R.. 04.05.2017 - 03:02
fuente
7

El control de cookies no es una buena solución para su problema, que no está tan bien definido. Podría pasar mucho tiempo evitando que los usuarios envíen sus cookies, pero es probable que bloquee el acceso legítimo las veces que perderá la buena voluntad de sus clientes, y es probable que el esfuerzo no sea proporcional a los beneficios. Algunas posibles estrategias alternativas serían:

  • Limitando la cantidad de dispositivos desde los que se puede ver una cuenta de usuario para iniciar sesión. Si ve una cuenta de usuario activa en 3 dispositivos o eso puede ser un signo de abuso
  • Seguimiento de ubicación geográfica, si se accede a una cuenta de usuario en Boston y Beijing al mismo tiempo, podría ser un abuso.
  • Introduciendo la autenticación de 2 factores de algún tipo, un usuario tendría que poner un código adicional de vez en cuando. Para ser honesto, esto es problemático, su instalación y mantenimiento son caros, y hay personas que constantemente olvidan sus pines para obtener un token. En el lado positivo no puedes compartir generadores de fichas. Alguien todavía podría enviar su código de token a otra persona, pero hace que sea más difícil compartir las credenciales
  • Monitoree los patrones de abuso de usuarios, puede usar algún tipo de algoritmo de aprendizaje automático en las estadísticas de los usuarios o simplemente los umbrales antiguos como sugiere @cloudfeet
  • Tiene preguntas de seguridad adicionales que requieren información personal como respuestas. Pocas personas confiarán esta información a otra persona, a menudo sería lo mismo que se pide en un sitio web bancario o similar, por lo que no les recomendaría compartirla. Esto presenta problemas para usted como propietario de un sitio web, ya que ahora es responsable de obtener más información personal
  • Envíe correos electrónicos periódicos para recordarles sus obligaciones, no detendrá a todos, pero los empujes amables y corteses funcionarán para algunos
respondido por el GdD 03.05.2017 - 16:34
fuente
5

Creo que todas las respuestas anteriores son incorrectas. @Andy probablemente respondió a tu pregunta, aunque de forma demasiado vaga. El problema es que (a) está asumiendo que sus usuarios son un vector de amenaza (explotar las cookies para obtener acceso no autorizado) (b) que desea usar cookies como parte de su mecanismo de autenticación. A medida que sucede, lo que realmente desea implementar es un tipo de seguridad de confianza cero, un modelo que dice que no se debe confiar en ningún usuario en ningún caso en ningún aspecto (esto es bastante difícil de entender al principio).

Básicamente, la implicación es que puede usar cookies, pero estas deberían ser simplemente cookies de sesión. Shibbeloth y otros diseños similares para instituciones académicas en el Reino Unido, utilizan una combinación de cookies de sesión, autenticación de terceros (en la institución) y autenticación de sesiones basada en la base de datos (en comparación con las otras dos). De hecho, por lo general también verifica los derechos de los usuarios en la institución (es decir, si está estudiando ciencias de la computación, no necesita la biblioteca médica, etc.).

Entonces, usar una cookie persistente es su problema, este es un no-no definitivo. Parece que ya comprendes el riesgo de usar una cookie persistente, que es que puede ser robada (generalmente en texto plano). Por lo tanto, utilice cookies de sesión no persistentes en el peor de los casos.

Lo que debería hacer, en mi opinión, si usara este método de autenticación es revocar las cookies con regularidad y requerir que el usuario vuelva a iniciar sesión. Como he explicado, Shibbeloth tiene múltiples factores de diseño ya que compara tus credenciales con las de tu universidad. Mejores diseños no solo compararían la información del usuario, sino que requerirían más de una credencial (es decir, un mensaje de texto, correo electrónico o una respuesta secreta como en la banca en línea).

De manera realista, la mayoría de las aplicaciones que están basadas en la web pueden beneficiarse enormemente de ser apátridas (dependiendo de la aplicación y los requisitos del usuario / sistema). Por lo tanto, puede eliminar las cookies de la sesión casi por completo al usarlas hasta que la ventana del navegador se cierre / el tiempo transcurrido o mediante el uso de un almacén de usuarios del lado del cliente cifrado (mejor solución).

Entre otras mitigaciones que otros usuarios han dicho, como los navegadores de huellas digitales y los patrones de uso de monitoreo, hay muchas estrategias que podría emplear. También puede usar listas blancas de IP, anti-DDoS, reinversión de credenciales regulares, etc. Son complementarias, pero no son una solución por sí mismas.

Lo que nunca debe hacer es eliminar la prioridad de las fallas de seguridad y software para mejorar la experiencia del usuario (por cierto, son lo mismo). Si hace esto, un día podría ser responsable de una catástrofe de protección de datos (y posiblemente ir a la cárcel y / o perder mucho dinero).

Para implementar completamente lo que está buscando, use una aplicación web (probablemente basada en javascript) que no necesita ser instalada. Esa aplicación debe programarse para implementar completamente su API y hacer todo el trabajo pesado para el usuario. Lo ideal es que lleve a cabo el control de acceso basado en roles (RBAC) a través de esa API (identifique los diferentes grupos de usuarios que ha mencionado). Obviamente, el RBAC debe implementarse en el lado del servidor. No hay ninguna razón por la que su API no pueda proporcionar o enlazar directamente a este y almacenar tokens emitidos directamente, oa través de otro canal, como un tokenw basado en mensajes de texto.

Espero que esto te ayude a pensar en relación con tu diseño.

    
respondido por el Steven Walker-Roberts 04.05.2017 - 07:58
fuente
4

Haz como los bancos, Lyft y otras organizaciones están haciendo. Exija que el usuario reciba un mensaje de texto o correo electrónico con un código de validación antes de permitirle completar el progreso de inicio de sesión.

    
respondido por el Xavier J 03.05.2017 - 20:19
fuente
3

Esto suena muchísimo como EBSCO . Soy el administrador de una institución que utiliza el Premiere de Búsqueda Académica, PsycArticles, JStor y algunas otras suscripciones de EBSCO.

En este momento, nosotros (como muchos otros) confiamos en EZProxy , pero esta solución es cada vez menos viable. A medida que más contenido pasa SSL / TLS. Proxiar el tráfico cifrado no es una muy buena idea.

Puedo decirles que esta idea de que las instituciones no pueden hacer Shibboleth o SAML es cada vez más inexacta. Hay algunos por ahí, pero es hora de que entren en el programa y pongan en marcha un proveedor de identidad de SSO. Si mi institución sub-400 FTE puede hacerlo, ellos también pueden hacerlo. También puedes mirar a OAuth.

Como alternativa para aquellos con personal de TI verdaderamente incompetente, usted podría administrar las cuentas usted mismo. Requerir a las instituciones que carguen un informe cada término con direcciones de correo electrónico para profesores y estudiantes, enviar invitaciones para aquellos en la lista que son nuevos, extender la fecha de vencimiento para aquellos que regresan y suspender aquellas cuentas para la institución que es Ya no está en la lista.

Claro, como usuario podría dar acceso a otra persona, pero eso también es válido para cualquier otro servicio. Incluso con el sistema existente, podría iniciar sesión en la computadora portátil de otra persona mientras estoy en casa. Realmente no habrás perdido nada.

    
respondido por el Joel Coehoorn 05.05.2017 - 16:57
fuente
2

Envíe un correo electrónico al correo electrónico de su institución con un enlace que creará una cookie de corta duración (3 días) en su navegador, es decir, un solo uso. Las instituciones casi siempre tienen un correo electrónico. Permitirles ingresar al correo electrónico de su institución. Esto evita que la revista tenga que lidiar con las contraseñas en el sistema y permite que los profesores se pongan a trabajar.

    
respondido por el HSchmale 03.05.2017 - 23:33
fuente
1

Supongo que no te preocupa que se roben grandes sumas de dinero (como en una configuración bancaria). Por lo tanto, si la autenticación real de 2 factores o incluso el "físico" (lector de tarjetas) es demasiado para usted, ¿qué le parece esto?

  • Implemente la autenticación de inicio de sesión / contraseña regular (con HTTPS, por supuesto, como de costumbre).
  • Tome su cookie de sesión y cree una segunda cookie que consiste en hash(session_cookie + IP + secret salt) .
  • Si lo desea, agregue el ID de sesión SSL a ese hash (que no persiste en cerrar el navegador, lo que es bueno para usted). Esto podría conducir a un poco de inconveniente si alguna de las partes inicia una renegociación (lo que le otorgaría un nuevo ID de sesión y, por lo tanto, obligaría al usuario a iniciar sesión nuevamente).
  • Además de verificar la cookie de sesión, verifique también la IP del cliente para cada solicitud individual que use ese segundo bit de información (que, como se dijo, puede ser una segunda cookie o concatenada en la primera, no importa).

Ahora el usuario puede regalar la cookie al contenido de su corazón y nadie podrá usarla a menos que también pueda falsificar la dirección IP (algo poco probable en este escenario; probablemente mucho más difícil que el usuario original simplemente reenviando cualquier contenido que descargado legítimamente) y / o el ID de sesión SSL (imposible).

    
respondido por el AnoE 04.05.2017 - 00:27
fuente
1

Como nadie lo ha mencionado aún, otra marca que use una cookie en otro lugar más difícil sería huellas dactilares del navegador ; Básicamente, se examinan las propiedades del software y hardware utilizado que se filtran de alguna manera y se utilizan como "huella digital" para identificar el dispositivo utilizado.

Por supuesto, tendrá que enviar la huella digital del dispositivo a su servidor en algún momento para poder verificar que una sesión no se usó en un navegador y / o dispositivo diferente, por lo que un atacante determinado en este punto, podría intentar modificar los datos para que se correspondan con la información enviada por el navegador del usuario real. Aún así, dependiendo de su implementación, podría usarse para al menos elevar un poco la barra.

    
respondido por el user2428118 04.05.2017 - 14:15
fuente
1

La solución basada en cookies no impide que los usuarios vendan o alquilen sus cuentas; una mejor solución sería la autenticación de 2 factores administrada por el servidor basada en la dirección IP:

  • Permitir que las cuentas se registren en un pequeño conjunto de direcciones IP.
  • El inicio de sesión o el intento de utilizar una cookie de inicio de sesión fuera de este conjunto solicita un enlace de confirmación de correo electrónico con un recordatorio para evitar el acceso no autorizado.
  • Si se confirma la nueva área, se agrega al conjunto de ubicaciones autorizadas y se elimina la más antigua de la lista para dejar espacio.

El mantenimiento de un archivo de autenticación de 2 factores en la computadora del usuario final no funciona porque el usuario final también podría vender ese archivo, por lo que la autenticación de 2 factores debe manejarse en el lado del servidor.

También se detallan los campos de especialización y comportamiento de acceso de los usuarios finales. Por ejemplo, si una cuenta que pertenece a un profesor de física comienza repentinamente a descargar documentos de economía y sociología, obviamente, ciérrela.

Cantidades de datos del medidor (similares a los planes de datos móviles) en descargas por cuenta. Por ejemplo, el primer medio gigabyte de artículos que un usuario descarga cada semana se descarga normalmente, después de lo cual las descargas de ese usuario se aceleran a 200 KB / s (cambie los números como mejor le parezca). La mayoría de los artículos de revistas no son enormes y la aceleración de la descarga no afectaría a la mayoría de los usuarios normales, sin embargo, será increíblemente frustrante para los usuarios que descargan archivos en grandes cantidades.

    
respondido por el user1258361 04.05.2017 - 23:19
fuente
-2

Puede usar la autenticación de certificado de cliente (SSL), firmada por su organización. Esto debería ser en todo el Internet, algo así como una VPN, pero más simple y más barato.

    
respondido por el Agnes K. Cathex 05.05.2017 - 14:22
fuente

Lea otras preguntas en las etiquetas