Due richieste di password non sono MFA: cosa verifica un accesso VPN

La pagina di accesso chiede una password, poi un secondo segreto, e subito la distribuzione viene descritta come multifattore. A volte lo è. Spesso è un unico fattore raccolto due volte, perché entrambi i valori sono conoscenze che la stessa persona ha digitato dalla stessa memoria o dallo stesso appunto. Una cifratura di tunnel robusta non cambia questo, e nemmeno la parola «sicuro» nel nome del prodotto.

Separare l’affermazione dal meccanismo richiede una sola domanda: che cosa dimostra ogni passaggio, e a chi?

Un fattore è una prova, non un campo

L’autenticazione a più fattori significa che per lo stesso account viene verificato più di un tipo distinto di prova: qualcosa che l’utente sa, qualcosa che possiede, qualcosa che è. Due campi che raccolgono entrambi una stringa memorizzata sono un solo tipo di prova richiesto due volte. Può essere un controllo utile, dato che due segreti indipendenti sono più difficili da indovinare di uno, ma non è ciò che il termine descrive e non va conteggiato come tale in una valutazione del rischio.

Il lato della verifica conta quanto il lato della raccolta. Un codice generato su un dispositivo dimostra il controllo di quel dispositivo solo se il server lo verifica rispetto a un segreto legato a questo account e rifiuta le ripetizioni. Un codice condiviso che funziona per tutti, un codice senza limite di frequenza o una richiesta approvata su un dispositivo che non mostra mai che cosa si sta approvando sono tutti più deboli di quanto l’etichetta suggerisca.

Quindi, quando qualcuno chiede se la VPN ha l’MFA, chiedete che cosa dimostra il secondo passaggio e come il server lo lega. Se la risposta è «una seconda password dalla stessa directory», avete un fattore e una discussione sulle politiche, non un secondo fattore.

Il caso del certificato va letto, non dato per scontato

Un certificato client più una password sembra due fattori, e può esserlo: il certificato è conservato in un archivio o su un token, e la password è ricordata. Può anche essere uno solo, se il file del certificato si trova senza protezione nella stessa cartella del profilo della password salvata, o se il certificato è stato rilasciato a un dispositivo che più persone condividono senza responsabilità individuale.

La domanda da risolvere è chi o che cosa identifica il certificato. Un certificato del dispositivo dimostra che è presente una macchina gestita. Un certificato utente dimostra un’identità. Se la distribuzione rilascia un certificato per portatile e poi tratta la sua presenza come prova della persona, il secondo fattore è silenziosamente diventato una proprietà dell’hardware che chiunque tenga il portatile eredita.

Niente di tutto ciò rende i certificati una cattiva idea. Rende la distinzione tra garanzia del dispositivo e garanzia dell’utente meritevole di essere messa per iscritto, perché le due rispondono a domande diverse e un foglio di calcolo di conformità che le conta come una sola sopravvaluterà ciò che è protetto.

La fiducia nel gateway e la fiducia nell’utente sono problemi separati

Un secondo fattore non rende sicuro digitare le credenziali in un endpoint che non avete verificato. Il client deve riconoscere il gateway previsto, ed è a questo che servono il certificato del server e la configurazione di fiducia del client. Il phishing funziona spostando l’accesso su un server controllato dall’attaccante, e un codice monouso corretto digitato lì viene semplicemente inoltrato al servizio reale in tempo reale.

Ecco perché la scelta del metodo cambia l’esito più della formulazione della richiesta. I codici digitati da una persona possono essere inoltrati da chiunque sappia mostrare una pagina convincente, mentre i metodi crittografici che legano l’autenticazione all’origine e alla sessione specifiche resistono a quell’inoltro per progettazione. Quale dei due avete è una proprietà del metodo, non del numero di passaggi nella finestra di dialogo.

Seguite il flusso di registrazione e client supportato dal fornitore invece di avvitare una richiesta in più su un campo password. Un secondo passaggio fatto in casa di solito finisce da qualche parte tra i due, aggiungendo attrito senza il legame che rende il fattore significativo.

Il recupero è la seconda porta d’ingresso

Ogni accesso robusto ha una via di ritorno quando l’autenticatore va perso, e quella via è dove il progetto è di solito più debole. Se un agente di supporto può reimpostare il secondo fattore dopo una telefonata a un numero archiviato, la rotta più economica per l’attaccante è l’help desk, non la pagina di accesso.

Chiedete come funziona la sostituzione, chi la approva e quali prove richiede. Poi verificate che il materiale di recupero, come i codici di backup, sia conservato separatamente dalla credenziale primaria, così che un’unica compromissione non consegni entrambe. Le linee guida sull’identità digitale del NIST trattano il legame del verificatore e il ciclo di vita dell’autenticatore come parte del requisito, non come un ripensamento operativo.

Che cosa scrivere nella valutazione

Descrivete i fattori per tipo, indicate che cosa dimostra ciascuno e precisate come è legato all’account. Annotate se il metodo resiste all’inoltro e descrivete il percorso di recupero con la stessa cura dell’accesso.

Poi dite chiaramente se la distribuzione è multifattore secondo quella definizione. «Due password e un certificato di macchina» è una frase onesta, e dice a un lettore molto più di una casella di controllo che risponde sì.