Verifica l'affiliazione di un utente con un'organizzazione

Question

Verifica l'affiliazione di un utente con un'organizzazione

#1 da (3 voti)
#2 da (0 voti)

1

Sono responsabile IT presso un'organizzazione di studenti. Chiamiamolo FratA . FratA ha legami con le organizzazioni sorelle in altre città universitarie nel mio paese. Chiamiamo quelli FratB a FratZ . Questi legami inter-organizzativi sono formalizzati da un'organizzazione ombrello, di cui FratA - FratZ sono membri. Chiamiamolo SuperFrat .

SuperFrat sta pianificando un evento per tutti i membri studenti di FratA - FratZ , e vuole vendere i biglietti all'evento utilizzando un negozio web fornito da TicketSellingCorp . Tuttavia, la vendita di biglietti dovrebbe essere limitata ai membri delle organizzazioni FratA - FratZ .

TicketSellingCorp mi ha contattato con un'indagine insolita:

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.

Il problema principale è che una volta effettuato l'accesso, i nostri membri possono accedere non solo alle proprie informazioni, ma anche a molte informazioni su altre persone. Quindi se il membro Alice non è d'accordo con l'implementazione proposta da TicketSellingCorp , le sue informazioni saranno comunque esposte a TicketSellingCorp se Bob fa è d'accordo.

Ho detto a TicketSellingCorp che ritengo che questa sia una cattiva idea che contraddice gli interessi dei nostri membri e ho offerto loro un provider openID (inclusa un'implementazione client di esempio OSS) per FratA -website; uno che dice solo al client openID che l'autenticazione ha avuto successo o meno. Non condivide nemmeno alcuna informazione, come ad esempio un indirizzo email. La mia motivazione è che TicketSellingCorp può chiedere loro stessi gli utenti, quindi gli utenti sono responsabili della condivisione delle proprie informazioni.

La risposta di

TicketSellingCorp a questo era:

We cannot implement openID in our sales process.

C'è un altro modo di collaborare con TicketSellingCorp che non implica l'esposizione di tutte le informazioni personali dei nostri membri?

authentication openid

posta derabbink 10.09.2013 - 09:30

fonte

2 risposte

0

Abbiamo trovato un altro modo di fare le cose: quando gli utenti sono registrati nel nostro sito Web, troveranno un collegamento che li porterà alla "forma di cliente" della società. Parte di questo collegamento sono due parametri di richiesta: un numero (pseudo) generato casualmente e una versione crittografata di quel numero (una firma digitale). La crittografia avviene in modo asimmetrico (con la nostra chiave privata) e abbiamo dato all'azienda la nostra chiave pubblica. Se possono decrittografare il secondo valore, sanno che l'utente è venuto da noi.

Non è molto elegante, imho, ma funziona abbastanza bene.

Il motivo per cui non abbiamo optato per la risposta di Luc è che sospettavamo che i nostri utenti non avrebbero capito la procedura . Inoltre, dopo alcuni avanti e indietro con TicketSellingCorp , si è scoperto che erano più flessibili di quanto si fossero presentati inizialmente.

risposta data 11.09.2013 - 10:58

fonte

Leggi altre domande sui tag authentication openid

C'è un modo per bloccare Ultrasurf oppure posso farlo nuke McAfee? Modifica file host virtuale usando php [chiuso]

score 3 · Accepted Answer

Che ne dici di generare un codice speciale per ogni utente che può essere inserito sul sito web di TicketSellingCorp ? Puoi dare a TicketSellingCorp un elenco di codici validi. TicketSellingCorp può chiedere agli utenti il loro nome e altre informazioni personali al momento della registrazione, e questo potrebbe facoltativamente essere verificato sul tuo database in un secondo momento.

I codici dovrebbero essere generati casualmente per impedire alle persone di indovinare il codice di altre persone (impersonandole). 128 bit di casualità dovrebbero essere più che sufficienti per assicurarsi che non possano essere indovinati. Ad esempio, un modo semplice per ottenere i codici è ottenere 16 byte di output da un generatore di numeri pseudo-casuali sicuro ( /dev/urandom o in PHP openssl_random_pseudo_bytes ), quindi convertirlo in esadecimale e memorizzarlo da qualche parte nel database.

Se TicketSellingCorp è realmente impostato per l'accesso con l'account dell'utente, potresti far funzionare i codici come password secondarie che forniscono solo determinate informazioni. Inoltre, se sono così disposti a farlo, mi fiderei anche di meno.