Roman KuznetsovDov’è la MFA passwordless per Windows?
Passwordless è un termine molto in voga nel mondo moderno dell’autenticazione, con vari approcci che trovano spazio soprattutto nei prodotti basati sul web (si pensi alle passkey). Purtroppo, gli ambienti a dominio Windows non hanno mai avuto un supporto nativo per una vera MFA, se si escludono la MFA basata su Azure e Windows Hello for Business, quindi la maggior parte dei fornitori terzi offre il supporto MFA per Windows in combinazione con un approccio basato su password.
Sul mercato esistono pochissime soluzioni che offrono una vera MFA passwordless per Microsoft Active Directory on-premise, e SystoLOCK è l’unica completamente autonoma, self-hosted, che non dipende da alcun servizio cloud e supporta tutti gli scenari d’uso più comuni, dal login di sistema, all’impersonificazione e all’accesso alle condivisioni di rete, fino all’accesso RDP e VPN.
In cosa SystoLOCK si differenzia dalla MFA tradizionale?
L’approccio di SystoLOCK alla MFA è molto diverso da quello della maggior parte dei fornitori: pur essendo un vero sistema MFA, ossia utilizza 2 dei 3 fattori per autenticare un utente, non si basa sulla password dell’utente per farlo, né gestisce alcuna rotazione delle password in background. Più precisamente, mantiene set separati di credenziali crittografiche scollegate dall’oggetto utente in Active Directory e verificate al momento del login. Dopo aver verificato con successo queste credenziali, SystoLOCK rilascia all’utente un certificato di breve durata (valido solo per quel singolo login) e presenta questo certificato al domain controller, dove avviene l’autenticazione finale. Ecco uno schema dell’intero processo:
SystoLOCK si basa su istanze AD CS irrobustite (hardened), pensate per servire esclusivamente le proprie richieste.
È importante sottolineare che l’approccio non si ferma alla schermata di login, ma si estende a tutte le richieste di credenziali successive, tra cui l’accesso alla rete, l’impersonificazione dell’utente e l’elevazione dei privilegi:
E che ne è della password? Ebbene, SystoLOCK è essenzialmente una smartcard virtuale e si presenta come tale al sistema. Di conseguenza, è possibile applicare all’oggetto utente in AD l’impostazione “smartcard richiesta”, impedendo di fatto qualsiasi autenticazione basata su password e qualsiasi attacco di forza bruta o furto di credenziali.
SystoLOCK per RDP: un’armonia improvvisa
Accedere a una sessione RDP in modo corretto non è mai stato un processo banale. Quando si cerca di aggiungere la MFA al processo, emergono ulteriori problemi e, con un requisito NLA, ci si può ritrovare impantanati nella risoluzione dei problemi. Con i fornitori di MFA tradizionali, di norma si utilizza la password nel prompt RDP locale, se configurato in tal senso, per poi completare il secondo passaggio del processo MFA sulla schermata remota. Semplicemente, nell’architettura del protocollo RDP non c’è spazio per le credenziali MFA, da qui la dualità.
Quando abbiamo progettato SystoLOCK, volevamo semplificare l’esperienza utente ed eliminare questa dualità. Il flusso risultante è esattamente questo: si forniscono le credenziali una sola volta e si viene condotti direttamente nella sessione RDP senza bisogno di un secondo passaggio, sia che l’NLA sia applicato oppure no, l’esperienza è sempre vicina al single sign-on.
Un altro aspetto importante del supporto RDP è la prevenzione del furto di credenziali. Se si utilizza un semplice approccio basato su password o una MFA tradizionale e il client o l’host viene compromesso, la password inserita nel prompt di autenticazione RDP può essere rubata, a meno che Credential Guard non sia attivo lato server. La situazione non è migliore per quanto riguarda i furti di password lato client. Con SystoLOCK, poiché le password vengono di fatto eliminate dagli oggetti utente e i certificati utilizzati hanno una durata breve (con le relative chiavi private inaccessibili), non c’è modo per un aggressore di compromettere la sessione RDP.
E, naturalmente, supporta Devolutions Remote Desktop Manager immediatamente, senza alcuna configurazione aggiuntiva!
Computer offline e lavoratori da remoto
Poiché ogni login comporta l’emissione e la verifica di un nuovo certificato, durante il login è necessaria una connessione al server SystoLOCK, a un server dei certificati e a un domain controller. Questo può essere un problema per chi viaggia o lavora da casa senza una VPN attiva. Per colmare questa lacuna viene utilizzato un approccio diverso. Mentre i casi d’uso descritti in precedenza potrebbero semplicemente utilizzare un OTP, il login offline richiede l’uso di uno smartphone per accedere. Anche le credenziali memorizzate nella cache, una funzionalità di Windows, devono essere abilitate affinché i login offline funzionino; tuttavia, di solito sono già abilitate.
Una volta che un utente ha effettuato con successo il login a un computer utilizzando SystoLOCK (e a condizione che tale computer sia stato configurato da un amministratore per consentire i login offline), il computer scambierà alcune informazioni crittografiche con il server SystoLOCK e memorizzerà le chiavi crittografiche dello smartphone per un utilizzo successivo.
Quando l’utente tenta di accedere mentre è offline, il computer, non potendo comunicare con il server, comunica invece con lo smartphone visualizzando un codice QR. Quando questo QR viene scansionato, lo smartphone avvia una verifica delle credenziali sul server, fungendo da collegamento di rete mancante tra il computer e il server SystoLOCK. Se il server non è disponibile, lo smartphone verificherà crittograficamente l’identità del computer e dell’utente, se configurato per farlo. Se la verifica ha esito positivo, il telefono presenterà un codice numerico da inserire sul computer. Dopo che l’utente ha inserito questo codice nel prompt di login offline, il login è completo. Per l’utente, il login offline non appare molto diverso da quello online, rendendo l’esperienza fluida e senza interruzioni:
Lavorare offline non significa sempre essere completamente disconnessi dall’infrastruttura dell’ufficio. In alcuni casi, significa semplicemente stabilire una VPN prima di avviare un’applicazione dell’ufficio o una sessione RDP. SystoLOCK offre diversi approcci per ottenere la connettività richiesta.
Un approccio consiste nel controllare i client VPN supportati. Il client VPN di Microsoft e il client AnyConnect di Cisco sono supportati nativamente da SystoLOCK. L’unico requisito è che il gateway VPN accetti i certificati utente per l’autenticazione e sia in grado di verificarli rispetto ad Active Directory. L’altro approccio consiste nell’utilizzare il nostro plugin generico per server RADIUS, progettato per funzionare sotto un componente NPS su un server Windows.
Se si ha la fortuna di utilizzare i client VPN supportati nativamente, è possibile sfruttare la compatibilità PLAP di SystoLOCK e connettersi alla VPN ed effettuare il login al computer in un unico passaggio:
Cosa c’è di sbagliato nella 2FA tradizionale?
Sebbene “2FA” sia l’acronimo di autenticazione a due fattori, a volte viene utilizzato per riferirsi alla cosiddetta autenticazione a due passaggi. È proprio qui che risiede il problema principale: l’autenticazione eseguita in questo modo non è principalmente a due fattori, ma avviene in due passaggi: il primo è l’autenticazione vera e propria, mentre il secondo è una forma di conferma che può persino essere attivata, disattivata o configurata.
Applicato a un login Windows o RDP, ciò significa che l’utente fornirebbe prima la propria password, avverrebbe l’autenticazione effettiva rispetto a un domain controller e poi, se questo primo passaggio ha esito positivo, verrebbe eseguita una qualche forma di verifica aggiuntiva. Questa verifica, se parliamo di login locali o RDP, viene solitamente effettuata “iniettando” una schermata aggiuntiva appena prima dell’avvio della shell utente, e tale schermata viene utilizzata per comunicare il secondo fattore. Il trucco è semplice: se qui la verifica fallisce, la shell utente non si avvia mai e la sessione di login viene interrotta.
La maggior parte dei fornitori di MFA tradizionali, tra cui Duo, Thales ecc., utilizza questo espediente per eseguire la verifica del secondo passaggio, basandosi quindi in primo luogo su un’autenticazione basata su password che abbia esito positivo.
Il primo problema di questo approccio è che può essere applicato solo al processo di login. Se poi è necessario accedere a una condivisione di file o eseguire un programma come amministratore, si resta privi di quel secondo passaggio di verifica. Questo può essere un problema in sé (si pensi alla conformità!), ma porta ad altri problemi più importanti:
- La maggior parte degli altri dispositivi presenti nel dominio che non supportano la MFA possono comunque subire attacchi di forza bruta, e prima o poi li subiranno, se un dispositivo della rete “prende” un virus,
- Gli utenti sceglieranno password più semplici perché si sentono più sicuri utilizzando la 2FA al login, rendendo più facili gli attacchi di forza bruta,
- Le sessioni RDP possono essere dirottate e le credenziali della password rubate se il client o il server RDP viene compromesso. Queste password potrebbero poi essere utilizzate contro quei nodi che non supportano la MFA.
Questi sono solo alcuni dei problemi associati all’autenticazione a due passaggi; un altro buon esempio è la cosiddetta “MFA fatigue”, nota anche come attacco di MFA bombing, il tipo di attacco utilizzato nell’hack di Uber del settembre 2022. Questo e altri attacchi simili hanno portato alcuni ricercatori di Bleeping Computer, Sentinel One e PC Magazine a mettere persino in discussione l’efficacia della MFA nel suo complesso.
Approccio universale e prospettive future
Gli account di dominio utente Windows sono al centro dell’esperienza utente. Vengono utilizzati in molti modi diversi in molti scenari diversi, e questi scenari variano per complessità e approccio. Non si tratta solo di login e RDP: SystoLOCK è in grado di dialogare con ADFS, ad esempio, aprendo la strada al login passwordless a Office 365 con utenti gestiti localmente, ed è in grado di istruire RD Gateway e RDWeb a eseguire il SSO su una farm di applicazioni pubblicate. E naturalmente, SystoLOCK dispone di una propria app mobile Authenticator in grado di sostituire tutti gli altri autenticatori conosciuti finora. Qui è possibile trovare una varietà di moduli SystoLOCK disponibili per diversi componenti Windows.
L’obiettivo principale di SystoLOCK è eliminare le password offrendo al contempo la migliore esperienza utente e senza alcuna dipendenza da un servizio cloud. SystoLOCK realizza questo trasformando un set di credenziali in un altro. Questa trasformazione implica che il set iniziale può variare e, sebbene non ancora supportato, stiamo lavorando all’integrazione dei token FIDO2 e di altri mezzi di autenticazione nel flusso di lavoro.
Sta diventando opinione condivisa che il futuro dell’autenticazione sia passwordless. SystoLOCK è qui per supportare questa transizione sul fronte Windows, dove Microsoft finora non è riuscita a fornire un approccio adeguato alla MFA moderna.
Ulteriori informazioni:
- Sito del prodotto: SystoLOCK.com
- Pianifica una demo di SystoLOCK
- Dimostrazioni d’uso in una playlist YouTube
- Brochure di SystoLOCK
- Certificato del penetration test
- Contatti: via web o LinkedIn