Richiesta MFA VPN rifiutata: cosa deve fare il client

Una richiesta MFA rifiutata sembra un problema di rete e non lo è. Il server ha chiesto un secondo fattore, il fattore è tornato negativo o non è mai arrivato, e la sessione è stata rifiutata prima che esistesse un tunnel. Quello che succede dopo è una questione di comportamento del client: mostrare l’errore e lasciare che l’utente avvii un tentativo pulito, oppure riprovare in modi che generano altre richieste e finiscono per attivare la protezione dell’account. La seconda strada è quella per cui un codice digitato male diventa un account bloccato.

Verifica quale richiesta non è riuscita

Inizia identificando quale richiesta non è riuscita. Una notifica push, un codice TOTP, un’asserzione FIDO e un flusso SAML falliscono ciascuno in modo diverso, e il client di solito sa quale ha chiesto. Un rifiuto, una sfida scaduta e un errore di consegna che non ha mai raggiunto il dispositivo finiscono tutti nello stesso errore generico, quindi lo stato del client è spesso l’unico posto in cui la differenza sopravvive.

Vale la pena registrare quello stato con precisione. Annota l’identificatore della sfida o il riferimento della transazione, il tipo di fattore, la marca temporale e l’esito, ma mai il codice o l’asserzione. L’identificatore della sfida è ciò che permette a un amministratore di trovare l’evento dal lato del provider di identità; senza di esso la conversazione con l’assistenza inizia con «a un certo punto nell’ultima ora» e di solito finisce lì. Trattalo come metadato diagnostico, non come un segreto.

Riprova una volta, deliberatamente, con una nuova sfida

Un nuovo tentativo dovrebbe essere un tentativo nuovo con una sfida nuova, non una replica di quella vecchia. Quando il client riutilizza la sfida precedente, il provider di identità o la rifiuta come scaduta o, peggio, accetta un’approvazione pensata per il tentativo precedente. Richiedi una sfida fresca, mostrala e lascia che l’utente agisca su quella che è ora sullo schermo.

Due tentativi con una breve pausa tra loro sono un valore predefinito ragionevole; un ciclo illimitato non lo è. Se il secondo tentativo fallisce allo stesso modo, fermati e segnala invece di continuare.

Cosa non deve fare il client

Il client non deve fare diverse cose che sembrano utili e non lo sono. Non deve continuare a inviare notifiche push finché qualcuno non tocca «approva», perché così abitua gli utenti ad approvare richieste che non hanno avviato ed è esattamente il comportamento su cui contano i kit di phishing. Non deve ricadere su un fattore più debole perché quello forte ha fallito, e non deve disattivare il controllo dell’identità del server per aggirare un problema di certificato comparso nello stesso momento. Ognuna di queste tre scorciatoie trasforma un errore di autenticazione in un incidente di sicurezza.

Non deve nemmeno inghiottire l’errore in silenzio. Un client che chiude la connessione e mostra un indicatore di caricamento lascia l’utente senza idea se riprovare, attendere o chiamare l’assistenza. Mostra l’errore con il tipo di fattore e un codice breve, tieni il messaggio privo di segreti e rendi l’azione di nuovo tentativo esplicita invece che automatica.

Se la richiesta non è stata avviata dalla persona alla tastiera, l’azione corretta è lasciarla rifiutata e segnalarla attraverso il canale di assistenza verificato. Approvare una richiesta per far cessare il rumore è il modo di fallire, non la soluzione.

Cosa registrare per l’assistenza

Per l’assistenza, il resoconto utile è piccolo. L’ora approssimativa con il fuso orario, l’account, il client e la versione, il tipo di fattore e lo stato non segreto di ogni tentativo: richiesto, negato, scaduto, approvato ma rifiutato dalla policy.

Tieni d’occhio anche gli orologi del client e del server. TOTP è un controllo a finestra temporale, quindi un dispositivo con l’orologio spostato produce codici dall’aria valida che falliscono ogni volta, e un client che segnala un codice non valido senza notare lo spostamento manda le persone a reimpostare credenziali che non erano mai sbagliate. Un utente il cui accesso fallisce ripetutamente dovrebbe controllare la versione supportata del client, lo stato di registrazione e il flusso di recupero documentato prima di generare altre richieste.

Il percorso di recupero merita la stessa cura del percorso di accesso. Un flusso per dispositivi smarriti esiste proprio perché un rifiuto non diventi un permesso di aggirare l’autenticazione, e un client dovrebbe collegare il processo documentato dell’organizzazione invece di improvvisarne uno.

La regola su cui costruire è che il rifiuto è un risultato, non un ostacolo. Segnalalo una volta, con chiarezza, con abbastanza contesto per agire, e lascia che il tentativo successivo sia nuovo. Le indicazioni di CISA su MFA resistente al phishing spiegano perché lo schema «chiedi finché non viene approvato» sia pericoloso fin dall’inizio, ed è il riferimento da citare quando qualcuno propone un ciclo di tentativi. Tutto ciò che il client aggiunge dopo un rifiuto dovrebbe rendere la decisione successiva più facile per una persona, non togliergliela.