Gestione delle identità: Utilizzo dell'autenticazione a due fattori per limitare le frodi

È possibile — e dovrebbe — utilizzare l'autenticazione a due fattori con dispositivi mobili e desktop.

Dan Griffin e Tom Jones

Il nucleo di tutte le transazioni basate su Web è il processo di gestione delle frodi. È essenziale per bilanciare l'inconveniente di autenticazione dell'utente con il rischio di essere falsificato. Metterlo un altro senso, quando c'è sufficiente conoscenza dell'identità dell'utente per consentire la transazione procedere?

Autenticare l'identità di un utente è già un problema difficile a fronte in continua evoluzione gli attacchi. Ora siamo nel mezzo di un importante cambiamento di paradigma. Dispositivi portatili, computer desktop non, sarà la piattaforma per la maggior parte delle transazioni.

Dispositivi mobili creano nuovi ostacoli alla protezione dei servizi Internet. Incoerente e goffe tastiere rendono scomodo per immettere le password complesse, così la maggior parte dei dispositivi offrono funzionalità per "ricordare" le password. I dispositivi mobili sono anche molto più facilmente persa o rubata più hardware desktop. Inoltre, le applicazioni mobili — compresi quelli che possono avere accesso alle password salvate — hanno dimostrato difficile da veterinario. Questi fattori espongono l'identità degli utenti a rischio supplementare.

C'è un altro modo per visualizzare la proliferazione di dispositivi mobili. Non è necessariamente un problema, ma una soluzione ai precedenti metodi di autenticazione bloccato in una battaglia persa con gli sviluppatori di malware e ladri.

Il percorso di comunicazione separata — vale a dire, la rete cellulare — a più mobile consente di dispositivi, si fortificano le barriere incontrate da qualsiasi malware. È possibile utilizzare tale percorso separato per associare l'utente a un numero di telefono specifico. Successivamente, l'associazione utente-a-cifre (o solo avere un chip SIM specifico) può essere riconfermati come necessaria durante le transazioni online. Questo si traduce in un aumento esponenziale del numero di tentativi che un utente malintenzionato avrebbe bisogno di montare per ottenere lo stesso livello di successo.

Numero di telefono come prova

Utilizzando i numeri di telefono per ridurre le frodi online non è nuovo. Le banche sono state impiegando questa tecnica per anni. Novità è la possibilità per qualsiasi servizio online, piccolo o grande, di incorporare facilmente questa funzionalità.

Microsoft ha recentemente acquisito PhoneFactor, una soluzione di autenticazione multifattore cellulare. Ora è disponibile per i clienti come attiva l'autenticazione di Windows Azure. Con PhoneFactor, quando un servizio online richiede autenticazione a due fattori, il telefono può fornire il secondo fattore in una varietà di modi:

  • Il server effettua una chiamata automatica al telefono con un messaggio vocale, tra cui un codice segreto una tantum. L'utente poi digita il codice in un form Web per completare la transazione online desiderata.
  • Può anche inviare un messaggio SMS, invece di un messaggio vocale, per trasmettere il codice di una tantum e dimostrare il possesso di utente del dispositivo.
  • Una variazione del processo precedente è quello di configurare il sistema per permettere all'utente di rispondere direttamente il SMS (o un albero di telefono durante una chiamata vocale). Ciò evita di dover ricordare il codice mentre passa da uno schermo o una finestra a altra e di dover fare ulteriori digitando. Invece, il servizio Web online è notificato in modo asincrono della risposta SMS valida da parte dell'utente, e la transazione richiesta, che era stato in sospeso, è autorizzata.
  • Un'app mobile PhoneFactor-consapevole può ricevere e rispondere correttamente a un autenticatore dal servizio cloud. A differenza delle precedenti variazioni, questo approccio richiede esplicitamente un app smartphone installato sul dispositivo mobile.
  • È possibile inoltrare un token morbido (come OAuth) inviato al PC o al telefono al servizio consumando il reclamo. Il server PhoneFactor non è coinvolto nella spedizione il token e non ha nemmeno bisogno di sapere dove viene inviato.

Dato il presupposto che molti utenti hanno già loro telefono la maggior parte del tempo, il beneficio è autenticazione multifattore senza il costo di solito hardware incrementale (token). Questo approccio può avere un impatto drammatico sulla tua curva rischio/ricompensa di frode.

Ora immaginate che sei uno scrittore di malware cercando di attaccare un sito Web che richiede questo tipo di autenticazione. Attacchi tipici concentrano sul dispositivo o il percorso di comunicazioni al dispositivo. Un attacco contro la connessione HTTP (TLS) è insufficiente per ottenere accesso al servizio Web, perché il codice di autorizzazione viene inviato tramite cellulare. Per avere successo, un attacco deve compromettere entrambi i canali.

Minacce emergenti

È bene capire le minacce mitigate dalla nuova tecnologia, e come e quando vengono introdotte nuove minacce. Fortunatamente, i rootkit non ancora diventati un fattore nella sicurezza del telefono. PhoneFactor opera a livello di applicazione e quindi non offre alcuna attenuazione delle minacce rootkit.

Presso l'app livello, aggiungendo un secondo fattore con nessun percorso di comunicazioni in comune con altri fattori è significativo. È importante assicurarsi che non ci sia nessun codice condiviso tra i percorsi. Ciò significa che l'utente deve essere coinvolto a un certo livello, sia copiando un codice PIN da un processo a altro o accettando una sfida al telefono che viene poi inoltrato utilizzando uno dei meccanismi descritti qui.

Qualsiasi interazione che non comporta un essere umano nel processo è aperta all'attacco elettronico. D'altra parte, nuove minacce a uno dei percorsi autenticazione non introducono una minaccia maggiore rispetto a quello che è già poste da password statiche.

Perché il codice di autorizzazione è diverso per ogni accesso di ogni utente, un attacco riuscito app-livello non consente il libero accesso al servizio Web dall'utente malintenzionato. Così, il valore dell'attacco è ridotto.

Gli aggressori sono interessati il massimo ritorno per il minor costo, quindi utilizzando l'autenticazione multifattore li incoraggia a cercare altrove più facili guadagni. Rendendo relativamente poco costoso per implementare l'autenticazione multifattore, servizi come PhoneFactor riducono la probabilità di che un attacco avrà successo.

Fantasia giocattoli vengono frequentemente con un avvertimento stampato all'esterno della scatola: "Qualche assemblea richiesta." È lo stesso con PhoneFactor. Per aiutare la muta i requisiti tipici di integrazione, il resto di questo articolo descrive soluzioni utilizzando PhoneFactor in due diversi scenari.

Accesso Web

Per l'accesso al Web interoperabile, l'obiettivo è quello di utilizzare PhoneFactor per l'autenticazione forte. Quindi è possibile rappresentare l'identità dell'utente con un formato token Web standard. Mentre il back-end contatti il telefono dell'utente, è possibile utilizzare PhoneFactor in basata su browser Web scenari di autenticazione da in sospeso la richiesta. Una volta che l'utente si autentica, aggiorna la pagina Web e l'utente è libero di procedere con le operazioni sensibili.

Per questo lavoro, l'applicazione Web deve considerare attendibile il servizio PhoneFactor per autenticare l'utente. Essa dovrà restituire qualche rappresentazione dell'identità dell'utente o di altri attributi utente. Quando possibile, applicazioni Web dovrebbero essere progettate per utilizzare formati di token basati su standard, come SAML Security Assertion Markup Language () o JSON Web Token (JWT). Questo aiuta a renderli interoperabili.

PhoneFactor con Active Directory

PhoneFactor non è solo per l'autenticazione Web, però. Esso consente inoltre di effettuare l'autenticazione utente più sicuro senza troppi disagi per gli account di accesso Windows desktop. Microsoft ha da tempo riconosciuto la necessità di sostenere i metodi di autenticazione alternativo su Windows.

L'API del Provider di credenziali offre questa estensibilità. Per iniziare il processo, l'utente scarica un Provider di credenziali (CP) al dispositivo. Quando l'utente tenta di accedere, il CP invia un messaggio al servizio di autenticazione back-end, richiedendo una sfida PhoneFactor. Il CP fornisce una casella di modifica all'utente di digitare il codice ricevuto sul suo cellulare.

Una volta che il codice viene verificato, il sistema di autenticazione back-end prende il passaggio aggiuntivo di emettere un certificato di breve durata infrastruttura a chiave pubblica (PKI) per l'utente. Il CP utilizza un certificato per eseguire un accesso di Kerberos. Come un ulteriore livello di protezione, si può avere la chiave privata del certificato associato al chip di sicurezza tipo parametro modello (TPM) sul dispositivo client. Può anche essere associato a un PIN casuali generati da CP. Questo si traduce in una credenziale non esportabili, multi-fattore che può interagire con l'hardware e le applicazioni esistenti.

Questo approccio ha il vantaggio di colmare il divario tra PhoneFactor come la nuova modalità di autenticazione e l'infrastruttura di Active Directory esistente. Ci sono parecchi componenti coinvolti nell'autenticazione Windows desktop a due fattori:

  • L'utente accede con la password di dominio esistenti, oltre a un codice segreto fornito da PhoneFactor. Questo modello utilizza un servizio Web di fiducia per gestire l'interazione tra il client e il back-end PhoneFactor.
  • Il CP acquisisce un certificato dall'autorità di certificazione (CA) e accede all'Active Directory di Windows. Il servizio Web di fiducia utilizza il token SAML da Active Directory Federation Services (ADFS) per acquisire il certificato per l'accesso al Kerberos/PKINIT.

Mentre questo scenario ha l'utente inserendo il perno nel computer appartenente al dominio, è inoltre possibile installare un app del telefono che permette all'utente di accettare la richiesta al telefono con un solo clic.

I vantaggi dell'autenticazione a due fattori sono ben noti, ma sono state difficili da realizzare in pratica la spesa nell'ottenere il secondo fattore nelle mani degli utenti. Questi sono un paio di modi per estendere la nuova tecnologia di Microsoft PhoneFactor nei regni autenticazione di accesso interattivo intranet, così come accesso Web basati su standard.

Tom Jones

Tom Jones era la sedia fondatore della ASC X9A10 sottocommissione standard nazionale americano per i pagamenti elettronici. Ha lavorato all'interno della Comunità di servizi finanziari con più organizzazioni tra cui Electronic Data Interchange (EDI X 12) e Accredited Standards Committee X 9 Inc. i pagamenti elettronici, nonché primo dati Corp., Intel Corp. e Microsoft.

 

Dan Griffin

**Dan Griffin**è il fondatore di JW Secure Inc e un sicurezza aziendale Microsoft MVP. Egli è l'autore dei libri "Cloud Security e di controllo" (CreateSpace indipendente piattaforma di Publishing, 2012) e "i quattro pilastri degli Endpoint Security: Salvaguardare la rete nell'era del Cloud Computing e il portare-vostro-proprio-dispositivo Trend "(CreateSpace Independent Publishing Platform, 2013). Egli è anche un oratore frequenti conferenze e blogger a jwsecure.com/dan.

Contenuti correlati