Come dovrebbe essere disabilitata la 2FA da un servizio?

TL; DR È una cosa di sicurezza contro usabilità. Preferisco, e sostengo, il modo in cui GitHub lo fa; Se l'utente ha già effettuato l'accesso con una sessione 2FA, richiedere la password quando si accede all'area dell'account "sensibile" (modifica dell'indirizzo email o 2FA) e quindi consentire la disattivazione di 2FA. Una volta disabilitato, invia un'email di notifica.

Questo è in gran parte una lotta tra l'esperto di UX e l'esperto di sicurezza. Da una parte, se il responsabile della sicurezza può farla franca, richiederanno la password, il token di conferma dell'email, il token 2FA e forse anche un token SMS. Ma questo scoraggerà solo gli utenti che probabilmente manterranno 2FA disabilitato per sempre dopo aver attraversato l'orrore di una UX.

Se l'utente ha già effettuato l'accesso utilizzando 2FA, è ragionevole presumere che questa sessione in questo browser non sia avviata da un utente malintenzionato. Pertanto, richiedere 2FA mentre si è ancora nella stessa sessione è eccessivo. Tuttavia, richiedere la password è una buona pratica poiché la macchina potrebbe essere condivisa o lasciata incustodita dall'utente. Questo esattamente come fa GitHub:

Se l'utente non ha effettuato l'accesso: Segui il normale flusso di accesso 2FA e continua di seguito.

Se l'utente ha già effettuato l'accesso con una sessione 2FA:

1. L'utente che sta per entrare nella zona di pericolo per disabilitare 2FA:

2. Richiederelorodiri-autenticarsiconlapassword:

3. Offri loro l'opzione per disabilitare 2FA con nient'altro richiesto:

4. Infine, e molto importante, invia all'utente una notifica via email che 2FA è disabilitato.

A causa della natura di questo cambiamento, a differenza della modifica della password o della attivazione 2FA, non penso sia necessario qui forzare la disconnessione di tutte le sessioni.

La risposta qui dipende dalla propensione al rischio e dal profilo delle minacce dell'organizzazione. Come sottolinea @adi, in questo caso c'è un compromesso tra usuabilità e sicurezza.

Per me, consentire la rimozione di 2FA senza reinserire un qualche tipo di credenziali lascia le applicazioni a rischio, in cui un utente malintenzionato ha accesso a una sessione attiva (ad esempio tramite hijacking di sessione o in un ambiente PC condiviso), quindi è solo davvero adatto per applicazioni a basso rischio (e la domanda potrebbe essere, perché hai 2FA lì in primo luogo ...)

Quindi l'opzione è, cosa ti serve in termini di nuova autenticazione per eseguire la rimozione di 2FA.

Se consenti solo password + sessione autenticata (l'approccio github), allora stai rischiando in qualche modo attacchi di tipo malware per PC in cui un utente malintenzionato potrebbe avere una password statica (tramite un keylogger) e una sessione attiva (scaricando informazioni da il browser), ma una volta che l'utente malintenzionato ha accesso privilegiato al tuo sistema client, sei comunque in una brutta posizione.

Un'altra opzione potrebbe essere quella di richiedere un token fallback che è stato registrato quando 2FA è stato impostato. Questo è senza dubbio dannoso per l'esperienza utente (è molto facile perdere un token che si è configurato potenzialmente anni fa), e potenzialmente indebolito laddove l'utente fa cose come memorizzare i token in chiaro sul PC utilizzato per accedere.

Una terza opzione è quella di usare un altro canale per confermare l'azione. È probabile che ciò abbia senso solo per i sistemi a più alto valore (ad es. Online banking, accesso privilegiato aziendale interno). Qui l'utente viene convalidato tramite un altro meccanismo (ad es. Messaggio SMS, conferma fuori banda tramite una chiamata telefonica)

Non puoi chiedere loro di autenticarsi con la loro seconda credenziale perché ciò crea un catch-22 per gli utenti che hanno perso il loro secondo fattore (ad esempio, un token difficile posizionato in modo errato).

La rimozione di 2FA dovrebbe essere simile al flusso della password dimenticata. In entrambi i casi, l'utente ha dimenticato o perso uno dei suoi fattori; il flusso di lavoro per modificare il fattore, sia esso password o 2FA, dovrebbe soddisfare lo stesso livello di sicurezza, ma non può richiedere le credenziali o il fattore originale.

In genere questo tipo di flusso comporta l'immissione di dati di fattori alternativi (ad esempio indirizzo email e data di nascita, accompagnati da CAPTCHA) seguiti da un OOB OTP . Ad esempio, puoi inviare all'utente un link di ripristino o inviare un SMS ad un codice breve.

In ogni caso, le modifiche alle proprie credenziali devono sempre attivare una notifica via email o SMS in tal senso.