Verificar la afiliación de un usuario con una organización

1

Estoy a cargo de TI en una organización de estudiantes. Llamémoslo FratA . FratA tiene vínculos con organizaciones hermanas en otras ciudades universitarias de mi país. Llamemos a esos FratB a través de FratZ . Estos lazos interorganizacionales son formalizados por una organización paraguas, de la cual FratA - FratZ son miembros. Llamémoslo SuperFrat .

SuperFrat está planeando un evento para todos los miembros estudiantes de FratA - FratZ , y quiere vender boletos para el evento mediante una tienda web proporcionada por TicketSellingCorp . Sin embargo, la venta de boletos debe limitarse a los miembros de las organizaciones FratA - FratZ .

TicketSellingCorp me ha contactado con una consulta inusual:

We want users to type in their username and password to the FratA-website,
 so our web store can log in behind the scenes, scrape their personal/contact information
 from their normally protected profile page and use this information for ticket sales.
Don't worry about security, we won't store passwords, and our backups are encrypted.

El problema principal es que una vez que ingresamos, nuestros miembros no solo pueden acceder a su propia información, sino también a una gran cantidad de información sobre otras personas. Entonces, si el miembro Alice no está de acuerdo con la implementación propuesta de TicketSellingCorp , su información aún estará expuesta a TicketSellingCorp si Bob está de acuerdo .

Le dije a TicketSellingCorp que creo que esta es una mala idea que contradice los intereses de nuestros miembros, y les ofrecí un proveedor openID (incluida una implementación de cliente OSS de muestra) para FratA -website; uno que solo le dice al cliente openID que la autenticación fue exitosa o no. Ni siquiera comparte ninguna información, como una dirección de correo electrónico. Mi motivación para eso es que TicketSellingCorp puede pedirlo a los usuarios ellos mismos, por lo que los usuarios son responsables de compartir su propia información.

La respuesta de

TicketSellingCorp a esto fue:

We cannot implement openID in our sales process.

¿Hay otra manera de cooperar con TicketSellingCorp que no implique exponer toda la información personal de nuestros miembros?

    
pregunta derabbink 10.09.2013 - 09:30
fuente

2 respuestas

3

¿Qué hay de generar un código especial para cada usuario que pueda ingresarse en el sitio web de TicketSellingCorp ? Puede dar a TicketSellingCorp una lista de códigos válidos. TicketSellingCorp puede pedirles a los usuarios su nombre y otra información personal cuando se registren, y esto podría verificarse en su propia base de datos más tarde.

Los códigos deben generarse de manera aleatoria para evitar que las personas adivinen el código de otras personas (suplantarlos). 128 bits de aleatoriedad deberían ser más que suficientes para asegurarse de que no se puedan adivinar. Por ejemplo, una forma fácil de obtener códigos es obtener 16 bytes de salida de un generador seguro de números pseudoaleatorios ( /dev/urandom o en PHP openssl_random_pseudo_bytes ), luego convertirlo a hexadecimal y almacenarlo en algún lugar de la base de datos.

Si TicketSellingCorp realmente se configura al iniciar sesión con la cuenta del usuario, podría hacer que los códigos funcionen como contraseñas secundarias que solo brindan cierta información. Además, si están dispuestos a hacer eso, confiaría en ellos incluso menos.

    
respondido por el Luc 10.09.2013 - 10:05
fuente
0

Encontramos otra forma de hacer las cosas: cuando los usuarios inician sesión en nuestro sitio web, encontrarán un enlace que los llevará a la "forma de cliente" de la compañía. Parte de este enlace son dos parámetros de solicitud: un (pseudo) número generado aleatoriamente y una versión encriptada de ese número (una firma digital). El cifrado se realiza de forma asimétrica (con nuestra clave privada) y le dimos a la empresa nuestra clave pública. Si pueden descifrar el segundo valor, saben que el usuario vino de nosotros.

No es muy elegante, imho, pero funciona lo suficientemente bien.

La razón por la que no optamos por la respuesta de Luc es que sospechamos que nuestros usuarios no entenderían el procedimiento. . Además, después de un cierto tiempo con TicketSellingCorp , resultó que eran más flexibles de lo que inicialmente se presentaron.

    
respondido por el derabbink 11.09.2013 - 10:58
fuente

Lea otras preguntas en las etiquetas