Quando dovrei inviare più di un dispositivo multifattore a un utente? Va bene dare diversi gettoni attivi contro nessuno?

Ho diversi dispositivi di autoapprendimento multifattoriali collegati al mio account paypal. Ho anche due diversi dispositivi di autenticazione multi-fattore che proteggono il mio accesso a stackexchange. È sicuramente possibile farlo.

Ci sono molti requisiti per farlo. Uno è semplice comodità (mi autenticano con il dispositivo più vicino a me in quel momento). Un requisito più formale potrebbe sorgere perché diversi token sono emessi a diversi livelli di Assurance (LoA) - Ho più credenziali a diversi livelli di garanzia. Potrebbe essere utile per me accedere con una credenziale di bassa sicurezza, ma se voglio intraprendere un'azione che richieda una maggiore sicurezza, potrei aver bisogno di ri-autenticarsi con una credenziale diversa.

@ Lucas Kauffman è del tutto corretto; Io NON voglio che i miei amministratori si colleghino con le stesse credenziali quando navigano su internet che fanno quando stanno aggiustando i miei server.

Questa risposta potrebbe facilmente andare avanti a libro ed essere al di fuori dell'ambito di SEC: SE. La Strategia nazionale per le identità affidabili nel cyberspazio (NSTIC) può essere vista come una risposta alla domanda.

Se il tuo utente è un utente test e ha bisogno per esempio di accedere a un account con admin, un account normale e speciale (non rendendolo un account amministratore ma anche più privilegi del normale). Quindi potrebbe essere necessario più di un token.

Inoltre, questo accade nella pratica quando un singolo account non può eseguire azioni A e B. Se l'utente ha bisogno di accedere alle azioni A e B, potrebbe essere necessario emettere due token. (Se lo fai, assicurati di mantenere una buona separazione delle funzioni). Questo è tuttavia un modo per ovviare a una limitazione all'interno dell'applicazione.

La "saggezza comune" che un solo dispositivo è necessario per un'organizzazione è una questione di costo: se un token costa $ 60 ciascuno e ci si fida già per proteggere l'accesso più sensibile, è possibile riutilizzarlo per fornire un accesso inferiore. Lo stesso token potrebbe essere associato al tuo account "admin", al tuo account "regolare" e al tuo account "sistema di test" di basso livello. L'onere dell'utente è di utilizzare l'account appropriato per la situazione.

È importante capire che il token è associato alla tua identità e non al tuo livello di autorità. Di per sé, il token non concede l'autorizzazione di amministratore. Il token è associato a te e al tuo account ed è l'appartenenza del tuo account al gruppo di utenti admin che concede l'autorizzazione dell'amministratore.

Dove sono necessari più token è quando due diverse organizzazioni concedono l'accesso e le due organizzazioni non sanno, parlano o si fidano l'un l'altro. Potresti avere un token emesso da un venditore per accedere al sito del fornitore e, se non hai un contratto di accesso federato con loro, posso capire di emettere un secondo token. Ma ci sono pochi motivi per portare gli utenti a portare in giro 8 diversi token e molti motivi per non - costo per token e confusione dell'utente (quale di questi tre token identici utilizzerò per l'account di laboratorio?)

... per ogni ambiente

A seconda dei requisiti di sicurezza di ciascun ambiente, (test, dev, qa, prod) dovrebbe esserci un token separato. Questo può prevenire problemi operativi in cui uno script di test di controllo qualità "perde" in produzione e influenza il servizio.

... per ogni ruolo

I token dovrebbero essere unici in base al rischio per le operazioni che pone: (Domain Admin, CA admin).

... più token per accesso

Non l'ho mai visto in produzione ma posso immaginare uno scenario in cui qualcuno è sfidato per nome utente, password, password HTOP e password Yubikey.

.. come appropriato per le esigenze di sicurezza

Penso che ci sia una via di mezzo tra non avere affatto un dispositivo multifattore, invece di avere un solo token assegnato. Nello specifico, una volta che la sicurezza IT ostacola l'usabilità del sistema, gli utenti troveranno un modo per aggirarlo. Ecco un utente che sta utilizzando una videocamera per automatizzare da remoto la sua sfida per il portachiavi RSA .

Se un utente sta usando questa tecnica, o semplicemente usando una Webcam puntata su un token, allora potrebbe essere una buona idea scoprire perché. Se si vuole ridurre il portachiavi fisico gonfio, o perché potrebbero perderlo, allora forse emettere quell'utente più token potrebbe risolvere il problema. Per esempio; un YubiKey nano potrebbe essere inserito in un PC domestico e di lavoro. Dato che il nano è difficile da rimuovere, potrebbe avere senso avere anche un token USB portatile.

La sicurezza è leggermente più diluita del modello da un token per persona, ma è ben lontana dal non avere alcun fattore multifunzione. In questo caso, l'area superficiale di attacco viene ridotta in modo tale che le sessioni casuali di tokenless vengano rifiutate.

Gli svantaggi di richiedere più di due fattori di autenticazione diventano evidenti quando si risponde alla domanda: "un utente dovrà fornire tutti questi fattori ogni volta per accedere al proprio account?".

Se la risposta è sì, mentre il sistema diventerebbe tecnicamente più sicuro (più informazioni dovevano cadere nelle mani sbagliate affinché lo schema di autenticazione fosse falsificato), diventerebbe anche meno user-friendly . Se l'utente aveva bisogno di inserire il proprio nome, una password segreta creata e memorizzata, il numero di una carta nel proprio portafoglio e il numero di una chiave di crittografia sul proprio portachiavi, allora è necessario sbagliare molto per l'account di un utente essere registrati da qualcuno diverso da quella persona. Tuttavia, solo una cosa deve sbagliare perché l'utente legittimo diventi bloccato dal proprio account (dimentica la password, perde la carta, perde le chiavi). Devono anche inserire tutte queste informazioni per accedere, ogni volta; Non so voi, ma l'utente medio considererebbe una barriera estrema all'ingresso.

Se la risposta è no, allora il sistema diventa meno sicuro; se l'utente potesse usare il proprio numero di tessera o della propria chiave crittografica, potrebbe comunque entrare se il loro portafoglio venisse rubato, ma un aggressore ora ha una scelta; può rubare il portachiavi dell'utente o del proprio portachiavi per ottenere un dispositivo che fornisca l'autenticazione necessaria, oltre alla password acquisita con un keylogger. Può scegliere l'obiettivo più facile, rendendo l'opzione una riduzione del livello di sicurezza totale.

Penso che dovrebbe essere possibile per ogni utente ottenere più chiavi, se la chiave viene persa o rubata (o nel caso di token che hanno la propria batteria, se la batteria muore) si dovrebbe sempre avere un token di backup, quindi puoi entrare (e disabilitare l'altro token per esempio)

questo è anche il motivo per cui Google, Github e Dropbox consentono più dispositivi U2F.