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

Hai bisogno di farlo?

Dalla mia esperienza all'interno / all'esterno di istituzioni accademiche con accesso a riviste, c'è sempre una certa quantità di risorse per la condivisione come favore ( es. "ehi, potresti inviarmi un PDF di questo documento?"). Non sarai mai in grado di fermarlo, perché in realtà viene effettivamente eseguito l'accesso manuale da un utente legittimo su una macchina corretta. Tuttavia, personalmente non ho mai visto studenti / personale che cercavano di trarre profitto da questo.

Monitoraggio

Anche se volessero fare soldi in questo modo, non credo che condividere i cookie è il modo migliore, non è certo come lo farei! Le protezioni che potresti aggiungere al sistema dei cookie (ad esempio, il rilevamento delle impronte digitali del browser dell'utente e il controllo che rimanga lo stesso, ecc.) Non si applicheranno ad altri metodi.

Invece (se questo è effettivamente un problema), un Una soluzione ragionevole e robusta consiste nel monitorare i modelli di utilizzo dell'utente. Se stanno scaricando 100 volte le risorse di chiunque altro o se recuperano risorse in modo coerente per 250 ore consecutive (gli esseri umani più lunghi possono sopravvivere senza dormire), allora 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 un secondo momento e fino a quando non avrai la prova che si tratta effettivamente di un problema, penso che dovrebbe essere abbastanza lontano elenco di cose da fare.

Tu no.

Questa domanda è fondamentalmente una variante di "Come faccio a eseguire il 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 ripubblicheranno le tue pubblicazioni su SciHub.

Il controllo dei cookie non è una buona soluzione al tuo problema, che non è così ben definito. Potresti dedicare molto tempo a impedire agli utenti di inviare i loro cookie, ma è probabile che blocchi l'accesso legittimo abbastanza volte da perdere la buona volontà dei tuoi clienti e lo sforzo è probabilmente sproporzionato rispetto ai vantaggi. Alcune possibili strategie alternative potrebbero essere:

• Limitare il numero di dispositivi da cui può essere visto un account utente per accedere. Se vedi un account utente attivo su 3 dispositivi circa, potrebbe essere un segno di abuso
• Monitoraggio della posizione geografica, se a Boston e Pechino si accede contemporaneamente a un account utente potrebbe essere un abuso
• Introducendo un qualche tipo di autenticazione a 2 fattori, un utente dovrebbe inserire occasionalmente un codice extra. Questo è problematico ad essere onesti, è costoso da configurare e mantenere e le persone dimenticano costantemente i loro pin per ottenere un token. Il lato positivo è che non puoi condividere generatori di token. Qualcuno potrebbe ancora inviare il proprio codice token a qualcun altro, ma rende più difficile condividere le credenziali
• Monitorare i modelli di utente per abusi, potresti utilizzare una sorta di algoritmo di apprendimento automatico sulle statistiche degli utenti o semplicemente vecchie soglie come suggerisce @cloudfeet
• Avere domande di sicurezza aggiuntive che richiedono informazioni personali come risposte. Poche persone si fideranno di qualcun altro di queste informazioni, spesso sarebbe uguale a ciò che viene chiesto su un sito Web bancario o simili, quindi li scoraggerebbe a condividerle. Questo crea problemi per te come proprietario di un sito web poiché ora sei responsabile di più informazioni personali
• Invia e-mail periodiche per ricordare loro i loro obblighi, non fermerà tutti, ma i pungoli gentili e cortesi funzioneranno per alcuni

Penso che tutte le risposte precedenti siano sbagliate. @ Andy probabilmente ha risposto alla tua domanda, anche se troppo vagamente. Il problema è che (a) presumi che i tuoi utenti siano un vettore di minacce (sfruttando i cookie per ottenere un accesso non autorizzato) (b) desideri utilizzare i cookie come parte del tuo meccanismo di autenticazione. In realtà, ciò che si vuole effettivamente implementare è un tipo di sicurezza zero trust, un modello che dice che nessun utente dovrebbe essere considerato attendibile in nessun caso (questo è abbastanza difficile da capire all'inizio).

Quindi, usare un cookie persistente è il tuo problema, questo è un deciso no-no. Sembra che tu abbia già compreso il rischio nell'utilizzo di un cookie persistente, ovvero che possa essere rubato (di solito in chiaro). Pertanto, nella peggiore delle ipotesi, utilizza cookie di sessione non persistenti.

Quello che dovresti fare, a mio avviso, se usassi questo metodo di autenticazione è revocare i cookie regolarmente e richiedere all'utente di accedere nuovamente . Come ho spiegato, Shibbeloth è multifattorizzato in base alla progettazione in quanto confronta le tue credenziali con quelle della tua università. I progetti migliori non si limiterebbero a confrontare le informazioni dell'utente, ma richiederebbero più di una credenziale (ad esempio un messaggio di testo, un'e-mail o una risposta segreta come nel banking online).

Realisticamente, la maggior parte delle applicazioni 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 interamente usandoli fino alla chiusura della finestra del browser / tempo trascorso o utilizzando un archivio utente lato client crittografato (soluzione migliore).

Tra le altre mitigazioni come hanno detto altri utenti, come il rilevamento delle impronte digitali e il monitoraggio dei modelli di utilizzo, ci sono molte strategie che potresti utilizzare. Potresti anche utilizzare la whitelist IP, l'anti-DDoS, il rollover regolare delle credenziali ecc. Questi sono complementari, ma non una soluzione di per sé.

Ciò che non devi mai fare è ridurre la priorità di sicurezza e difetti del software per l'utente esperienza di miglioramento (sono la stessa cosa tra l'altro). 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 necessita di essere installata. Quell'applicazione dovrebbe essere programmata per implementare completamente la tua API e fare tutto il lavoro pesante per l'utente. Idealmente dovrebbe eseguire il controllo degli accessi basato sui ruoli (RBAC) su tale API (quindi identifica i diversi gruppi di utenti che hai menzionato). Ovviamente, RBAC deve essere implementato sul lato server. Non c'è motivo per cui la tua API non possa fornire o collegarsi direttamente a questo e memorizzare i token emessi direttamente o tramite un altro canale come un token basato su messaggi di testo.

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

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

Sembra molto simile a EBSCO. Sono l'amministratore di un'istituzione che utilizza Academic Search 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 man mano che più contenuti diventano SSL / TLS. Il proxy del traffico crittografato non è una buona idea.

Posso dirti che l'idea che le istituzioni non possano fare Shibboleth o SAML è sempre più imprecisa. Ce ne sono alcuni là fuori, ma è tempo per loro di entrare nel programma e ottenere un provider di identità SSO. Se il mio istituto FTE con meno di 400 persone può farlo, possono farlo anche loro. Potresti anche guardare OAuth.

Come ripiego per chi ha personale IT veramente incompetente, puoi gestire gli account da solo. Richiedere alle istituzioni di caricare un rapporto ogni trimestre con indirizzi di posta elettronica per docenti e studenti, inviare un invito per coloro che sono nuovi nell'elenco, estendere la data di scadenza per coloro che stanno tornando e sospendere gli account per l'istituto che sono non più nell'elenco.

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

Inviare un'e-mail al proprio istituto con un collegamento che creerà un cookie di breve durata (3 giorni) nel browser, ovvero un utilizzo occasionale. Le istituzioni hanno quasi sempre un'e-mail. Consenti loro di inserire l'email dell'istituto. Ciò impedisce al giornale di dover gestire le password sul sistema e consente ai professori di mettersi al lavoro.

Presumo che tu non sia preoccupato per il furto di ingenti somme di denaro (come in una configurazione bancaria). Quindi, se l'effettiva autenticazione a 2 fattori o anche "ottenere fisico" (lettore di schede) è troppo per te, che ne dici di questo:

• Implementa la normale autenticazione di login / password (con HTTPS ovviamente , come al solito).
• Prendi il tuo cookie di sessione e crea un secondo cookie che consiste di hash (session_cookie + IP + secret salt) .
• Se tu quindi lo desideri, aggiungi l'ID della sessione SSL a quell'hash (che non persiste chiudendo il browser, il che è un bene per te). Questo potrebbe portare a un po 'di inconvenienti se una delle parti avvia una rinegoziazione (che ti darebbe un nuovo ID di sessione e quindi costringerebbe l'utente ad accedere di nuovo).
• Oltre a verificare il cookie di sessione, verifica anche l'IP del client per ogni singola richiesta utilizzando quel secondo bit di informazione (che, come detto, può essere un secondo cookie o concatenato nel primo, non importa) .

Ora l'utente può dare via il cookie a suo piacimento e nessuno potrà usarlo a meno che non possa anche falsificare l'indirizzo IP (piuttosto improbabile in questo scenario; probabilmente molto più difficile dell'utente originale che si limita a inoltrare qualsiasi contenuto scaricato legittimamente) e / o l'ID di sessione SSL (impossibile).

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

Ovviamente, dovrai inviare il dispositivo impronta digitale al tuo server ad un certo punto in modo da poter verificare che una sessione non è finita per essere utilizzata su un browser e / o dispositivo diverso, quindi un determinato aggressore potrebbe a questo punto provare a modificare i dati in modo che corrispondano alle informazioni inviate da il browser dell'utente effettivo. Tuttavia, a seconda della tua implementazione, potrebbe essere usato almeno per alzare un po 'il livello.

La soluzione basata sui cookie non impedisce agli utenti di vendere / affittare i propri account: una soluzione migliore sarebbe l'autenticazione a due fattori gestita dal server basata sull'indirizzo IP:

• Consenti agli account di registrarsi a un piccolo insieme di indirizzi IP.
• L'accesso o il tentativo di utilizzare un cookie di accesso esterno a questo insieme richiede un collegamento di conferma tramite posta elettronica con un promemoria per impedire l'accesso non autorizzato.
• Se il nuovo l'area è confermata, viene aggiunta alla serie di posizioni autorizzate e la più vecchia nell'elenco viene rimossa per fare spazio.

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

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

Misurare la quantità di dati (simili ai piani dati mobili) sui download per account. Ad esempio, il primo mezzo gigabyte di articoli che un utente scarica ogni settimana viene scaricato normalmente, dopodiché i download di quell'utente vengono limitati a 200 KB / s (cambia i numeri come meglio credi). La maggior parte degli articoli di giornale non sono enormi e la limitazione del download non interesserebbe la maggior parte degli utenti normali, tuttavia si rivelerà incredibilmente frustrante per i downloader di massa.

È possibile utilizzare l'autenticazione del certificato client (SSL), firmata dalla propria organizzazione. Dovrebbe essere a livello di Internet, un po 'come una VPN, ma più semplice ed economico.