Come impedirebbe a qualcuno di vendere il suo cookie persistente a qualcuno che non è un membro dell'istituzione e vuole ottenere l'accesso?

Puoi impedire a qualcuno di vendere la propria password per ottenere un accesso simile? Pensi di aver bisogno? È praticamente equivalente.

Hai bisogno di fare questo?

Dalla mia esperienza di essere all'interno / al di fuori di istituzioni accademiche con accesso alla rivista, c'è sempre una certa quantità di condivisione di risorse come un favore (ad esempio "hey, potresti inviarmi un PDF di questo documento?"). Non sarai mai in grado di fermarlo, perché in realtà è l'accesso manuale da parte di un utente legittimo su una macchina corretta. Tuttavia, personalmente non ho mai visto lo studente / il personale che cercava di guadagnare denaro da questo.

Monitoraggio

Anche se volevano fare soldi in questo modo, allora non credo che condividere i cookies sia il modo migliore - non è certo come lo farei io! Le protezioni che potresti aggiungere al sistema di cookie (ad esempio, prendere le impronte digitali nel browser dell'utente e controllarne la permanenza, ecc.) Non si applicano ad altri metodi.

Invece (se questo è effettivamente un problema), una soluzione ragionevole e robusta è monitorare i modelli di utilizzo dell'utente. Se stanno scaricando 100 volte le risorse di chiunque altro, o se recuperano le risorse in modo coerente per 250 ore consecutive (gli umani più lunghi possono sopravvivere senza dormire), probabilmente ci sono più utenti o un sistema automatizzato al lavoro.

Tuttavia, questa soluzione di monitoraggio non deve essere inclusa dall'inizio, può essere aggiunta in seguito - e finché non si ha la prova che è effettivamente un problema, penso che dovrebbe essere abbastanza in fondo alla lista delle cose da fare.

Non lo fai.

Questa domanda è fondamentalmente una variante di "Come faccio a fare DRM e farlo funzionare?" e la risposta è la stessa.

Non sono sicuro del motivo per cui "vendere un cookie persistente" sembra la tua minaccia principale. Normalmente gli utenti ripubblicano le tue pubblicazioni su SciHub.

Il controllo dei cookie non è una buona soluzione al tuo problema, che non è ben definito. Potresti spendere un sacco di tempo per impedire agli utenti di inviare i loro cookie in giro, ma è probabile che tu blocchi l'accesso legittimo abbastanza volte da perdere la buona volontà dei tuoi clienti, e lo sforzo rischia di essere sproporzionato rispetto ai benefici. Alcune possibili strategie alternative potrebbero essere:

• Limitazione del numero di dispositivi da cui è possibile visualizzare un account utente. Se vedi un account utente attivo su 3 dispositivi o che potrebbe essere un segno di abuso
• Monitoraggio della posizione geografica, se si accede a un account utente a Boston e Pechino allo stesso tempo potrebbe essere un abuso
• Introducendo l'autenticazione a 2 fattori di qualche tipo, un utente dovrebbe inserire un codice aggiuntivo occasionalmente. Questo è problematico per essere onesti, è costoso da configurare e mantenere, e la gente dovrebbe costantemente dimenticare i propri pin per ottenere un token. Sul lato positivo non è possibile condividere generatori di token. Qualcuno potrebbe ancora inviare il proprio codice token a qualcun altro, ma rende più difficile la condivisione delle credenziali
• Monitora i pattern utente per gli abusi, potresti usare una sorta di algoritmo di machine learning sulle statistiche degli utenti o semplicemente vecchie soglie come suggerisce @cloudfeet
• Avere altre domande di sicurezza che richiedono informazioni personali come risposte. Poche persone si fideranno di qualcun altro di queste informazioni, spesso sarebbe lo stesso di quanto viene richiesto su un sito Web bancario o simili, quindi scoraggerebbe loro la condivisione. Ciò introduce problemi per te come proprietario di un sito web, poiché ora sei responsabile per ulteriori informazioni personali
• Invia email periodiche che ricordino loro i loro obblighi, non fermerà nessuno, ma i pungoli gentili e cortesi funzioneranno per alcuni

Penso che tutte le risposte sopra siano sbagliate. @Andy probabilmente hai risposto alla tua domanda, anche se troppo vagamente. Il problema è che (a) si presuppone che i propri utenti siano un vettore di minacce (sfruttando i cookie per ottenere l'accesso non autorizzato) (b) si desidera utilizzare i cookie come parte del meccanismo di autenticazione. In realtà, ciò che si desidera implementare è un tipo di sicurezza di trust zero, un modello che afferma che nessun utente deve essere considerato attendibile in alcun caso (questo è abbastanza difficile da capire all'inizio).

Essenzialmente, l'implicazione è che puoi usare i cookie ma questi dovrebbero essere solo cookie di sessione. Shibbeloth e altri progetti simili per istituzioni accademiche nel Regno Unito, utilizzano una combinazione di cookie di sessione, autenticazione di terze parti (presso l'istituto) e autenticazione di sessione guidata da database (rispetto agli altri due). Di fatto, di solito controlla anche l'istituto per i diritti dell'utente (ad esempio se stai studiando informatica non hai bisogno della biblioteca medica, ecc.)

Quindi, usare un cookie persistente è il tuo problema, questo è un no-no definito. Sembri già capire il rischio nell'usare un cookie persistente, che è che può essere rubato (di solito in testo normale). Pertanto, utilizzare i cookie di sessione non persistenti nel peggiore dei casi.

Quello che dovresti fare, a mio avviso, se dovessi utilizzare questo metodo di autenticazione è revocare regolarmente i cookie e richiedere all'utente di effettuare nuovamente il login. Come ho spiegato, Shibbeloth è multi-factored by design in quanto mette a confronto le tue credenziali con quelle della tua università. I progetti migliori non si limitano a confrontare le informazioni degli utenti, ma richiedono più di una credenziale (ad esempio un messaggio di testo, un'e-mail o una risposta segreta come nel sistema bancario online).

Realisticamente, la maggior parte delle applicazioni che sono basate sul Web possono trarre enormi vantaggi dall'essere senza stato (a seconda dell'applicazione e dei requisiti dell'utente / di sistema). Quindi, puoi rimuovere i cookie di sessione dall'immagine quasi completamente, usandoli fino a quando la finestra del browser non viene chiusa / tempo trascorso o utilizzando un archivio utente crittografato sul lato client (soluzione migliore).

Tra le altre attenuazioni che altri utenti hanno detto, come ad esempio il rilevamento delle impronte digitali dei browser e il monitoraggio dei modelli di utilizzo, ci sono molte strategie che potresti impiegare. Potresti anche utilizzare la whitelist IP, l'anti-DDoS, il rollover delle credenziali regolari ecc. Questi sono complementari, ma non una soluzione di se stessi.

Ciò che non si deve mai fare è de-priorizzare la sicurezza e le imperfezioni del software per il miglioramento dell'esperienza utente (sono comunque la stessa cosa). Se lo fai, un giorno potresti essere responsabile di una catastrofe per la protezione dei dati (e potenzialmente andare in prigione e / o perdere molti soldi).

Per implementare completamente ciò che stai cercando, usa un'applicazione web (probabilmente basata su javascript) che non ha bisogno di essere installata. Quella applicazione dovrebbe essere programmata per implementare completamente la tua API e fare tutto il lavoro pesante per l'utente. Dovrebbe idealmente svolgere un controllo di accesso basato sui ruoli (RBAC) su quell'API (in modo da identificare i diversi gruppi di utenti che hai citato). Ovviamente, l'RBAC deve essere implementato sul lato server. Non vi è alcun motivo per cui l'API non può fornire o collegare direttamente a questo e memorizzare token emessi direttamente o tramite un altro canale, ad esempio un messaggio di testo basato su tokenw.

Spero che questo ti dia qualche spunto di riflessione in relazione al tuo design.

Fai come le banche, Lyft e altre organizzazioni stanno facendo. Richiedi che l'utente riceva un messaggio di testo o un'email con un codice di convalida prima di consentire il completamento dell'avanzamento del login.

Questo suona molto simile a EBSCO . Sono l'amministratore di un'istituzione che utilizza la ricerca accademica Premiere, PsycArticles, JStor e alcuni altri abbonamenti EBSCO.

In questo momento noi (come molti altri) ci affidiamo a EZProxy , ma questa soluzione sta diventando sempre meno sostenibile come più contenuto va SSL / TLS. Il proxy del traffico crittografato non è una buona idea.

Posso dirti che questa idea che le istituzioni non possono fare Shibboleth o SAML è sempre più imprecisa. Ce ne sono alcuni là fuori, ma è tempo per loro di ottenere con il programma e ottenere un provider di identità SSO in corso. Se la mia istituzione sub-400 FTE può farlo, anche loro possono farlo. Potresti anche guardare OAuth.

Come ripiego per chi ha personale IT davvero incompetente, è possibile gestire autonomamente gli account. Richiedere agli istituti di caricare un rapporto ogni termine con indirizzi e-mail per docenti e studenti, inviare inviti per quelli della lista che sono nuovi, estendere la data di scadenza per coloro che stanno ritornando e sospendere tali conti per l'istituzione che sono non più nella lista.

Certo, come utente potrei dare accesso a qualcun altro, ma è vero anche per qualsiasi altro servizio. Anche con il sistema esistente, potrei accedere al portatile di qualcun altro mentre sono a casa. Non avrai davvero perso nulla.

Invia tramite e-mail la loro e-mail dell'istituzione con un link che creerà un cookie di breve durata (3 giorni) nel browser, che è una tantum. Le istituzioni hanno quasi sempre una mail. Consentire loro di inserire la loro email di istituto. Ciò impedisce al journal di dover gestire le password sul sistema e consente ai professori di mettersi al lavoro.

Suppongo che tu non sia preoccupato per le forti somme di denaro rubate (come in un sistema bancario). Quindi, se l'autentica autenticazione a 2 fattori o anche "ottenere fisico" (lettore di schede) è troppo per te, che ne dici di questo:

• Implementare l'autenticazione di accesso / password regolare (con HTTPS, naturalmente, come al solito).
• Prendi il tuo cookie di sessione e crea un secondo cookie che consiste in hash(session_cookie + IP + secret salt) .
• Se lo desideri, aggiungi l'ID di sessione SSL a quell'hash (che non resiste alla chiusura del browser, il che è positivo per te). Questo potrebbe portare a un po 'di disagio se una delle parti avvia una rinegoziazione (che darebbe un nuovo ID di sessione e quindi costringerebbe l'utente ad accedere di nuovo).
• Oltre a verificare il cookie di sessione, verificare anche l'IP del client per ogni singola richiesta utilizzando quel secondo bit di informazioni (che, come detto, potrebbe essere un secondo cookie o concatenato nel primo, non importa).

Ora l'utente può regalare il cookie al suo contenuto e nessuno sarà in grado di usarlo a meno che non possa anche spoofare l'indirizzo IP (piuttosto improbabile in questo scenario, probabilmente molto più difficile rispetto all'utente originale che ha appena inoltrato qualsiasi contenuto scaricato in modo legittimo) e / o ID sessione SSL (impossibile).

Poiché nessuno lo ha ancora menzionato, un altro rende più difficile l'utilizzo di un cookie altrove fingerprinting del browser ; in pratica, esaminando le proprietà del software e dell'hardware utilizzati che sono trapelati in qualche modo e utilizzandoli come "impronta digitale" per identificare il dispositivo utilizzato.

Ovviamente, dovrai inviare l'impronta digitale del dispositivo al tuo server a un certo punto in modo da poter verificare che una sessione non sia stata utilizzata su un browser e / o dispositivo diverso, quindi un determinato utente malintenzionato potrebbe a questo punto provare a modificare i dati per corrispondere alle informazioni inviate dal browser dell'utente effettivo. Tuttavia, a seconda dell'implementazione, potrebbe essere usato per alzare un po 'la barra.

La soluzione basata su cookie non impedisce agli utenti di vendere / affittare i propri account: una soluzione migliore sarebbe l'autenticazione a 2 fattori gestita dal server in base all'indirizzo IP:

• Permetti agli account di registrarsi su un piccolo insieme di indirizzi IP.
• L'accesso o il tentativo di utilizzare un cookie di accesso all'esterno di questo set richiede un collegamento di conferma tramite e-mail con un promemoria per impedire l'accesso non autorizzato.
• Se la nuova area viene confermata, viene aggiunta al set di posizioni autorizzate e la più vecchia nell'elenco viene rimossa per fare spazio.

Il mantenimento di un file di autenticazione a 2 fattori sul computer dell'utente finale non funziona perché l'utente finale potrebbe vendere anche quel file, pertanto l'autenticazione a 2 fattori deve essere gestita lato server.

Indica anche i campi di specializzazione e comportamento di accesso degli utenti finali. Ad esempio, se un account appartenente a un professore di fisica inizia improvvisamente a scaricare in blocco i documenti di economia e sociologia, ovviamente bloccalo.

Quantità di dati del contatore (simile ai piani dati mobili) sui download per account. Ad esempio, il primo mezzo gigabyte di articoli scaricati dall'utente ogni settimana viene scaricato normalmente, dopo di che i download dell'utente vengono ridotti a 200 KB / s (modificare i numeri come meglio credi). La maggior parte degli articoli di giornale non è enorme e la limitazione del download non interesserà la maggior parte degli utenti normali, tuttavia si rivelerà incredibilmente frustrante per i downloader di massa.

Potresti usare l'autenticazione del certificato client (SSL), firmata dalla tua organizzazione. Questo dovrebbe essere a livello di Internet, un po 'come una VPN, ma più semplice ed economico.