Condivisione di token 2FA

1

Una società per cui lavoro vuole condividere un accesso a un'applicazione sensibile.

L'applicazione purtroppo non supporta più utenti, quindi una combinazione di nome utente / password è condivisa tra più persone tramite un gestore di password.

Vogliamo impostare 2FA per questo account, ma anche qui è implicito che tutti devono condividere lo stesso token 2FA.

Gli utenti vogliono farlo catturando uno screenshot del codice QR durante l'installazione, distribuendo il codice tramite Signal e memorizzando il codice QR (in un secondo gestore di password, nel caso in cui nuove persone si uniscano al team). Se qualcuno esce, vengono generati nuovi codici.

Quanto è ragionevole questo?

    
posta Evert 10.07.2018 - 21:14
fonte

3 risposte

2

Questo approccio risolve due dei problemi noti relativi agli account condivisi:

  • "Più persone hanno una password, più facilmente perde".
  • "Una volta che una persona esce, la password deve cambiare per tutti."

Non influenza il terzo. A seconda dell'applicazione, potrebbe essere più o meno importante:

  • "Quando l'utente apporta una modifica, non è possibile stabilire quale persona l'abbia eseguita."

Se non sei profondamente preoccupato per l'attribuzione, ma ritieni che sia più facile forzare le modifiche chiave e controllare la distribuzione delle chiavi con il nuovo schema, allora sì, questo è ragionevole.

Se speri di affrontare anche l'attribuzione, allora questo non sta apportando un cambiamento significativo.

Se riesci a mettere il tuo 2FA dietro un controllo dell'applicazione che è / per utente, allora puoi avvicinarti al raggiungimento di tutti loro. Le persone utilizzano le proprie credenziali individuali per ottenere il codice 2FA corrente da un'unica posizione centrale, quindi utilizzare tale codice per accedere all'applicazione e, correlando le due sessioni, è possibile determinare chi è stato registrato nell'applicazione per una determinata sessione. Il codice è in continua evoluzione e il dispositivo 2FA è centralizzato e non condiviso, pertanto gli utenti in partenza non dispongono dell'accesso in corso. E con un controllo di accesso adeguato per l'accesso al dispositivo 2FA, il problema di perdita è ridotto.

    
risposta data 10.07.2018 - 23:20
fonte
1

Se non puoi evitare di utilizzare un account condiviso, ciò che proponi è davvero una soluzione praticabile.

Tuttavia, potrebbe essere possibile emulare account separati se sei disposto a compiere ulteriori sforzi. Creare un servizio wrapper in grado di proxy del servizio di destinazione. Crea un account per ogni utente, con 2FA come desiderato, all'interno del wrapper. Ogni volta che un utente autorizzato si autentica sul wrapper, il wrapper esegue l'autenticazione al target e inoltra la sessione all'utente. In questo modo, solo il wrapper conosce i cred sull'account condiviso sulla destinazione e il wrapper può registrare ciò che gli utenti fanno ciò che usa la destinazione anche se la destinazione non può.

    
risposta data 10.07.2018 - 22:57
fonte
0

In termini semplici utilizzare un server Jump con 2FA / MFA (Multi Factor Authentication) davanti all'applicazione come livello di sicurezza. Quindi, ogni utente deve accedere utilizzando la propria identità al server di salto e da lì è possibile accedere al server di destinazione.

In questo modo puoi identificare l'utente con i dettagli della sessione su Jump / server di destinazione.

Questa è solo una soluzione, non una soluzione perfetta e potresti fare riferimento al link seguente per configurare il server di salto:

Jump Server per sicurezza

    
risposta data 11.07.2018 - 01:52
fonte

Leggi altre domande sui tag