Autenticazione a due fattori
Tutto ciò che hai letto in riguarda l'identificazione basata su ciò che sa l'utente che richiede. Lui conosce il proprio indirizzo email, sa come accedervi (ovvero, conosce la propria password email) e conosce le risposte alle domande segrete.
La "conoscenza" è considerata un fattore di autenticazione; gli altri due fattori comuni sono ciò che possiedi, ad esempio, un dispositivo fisico, e chi sei, ad esempio, impronte digitali o retina dell'occhio.
Nella maggior parte dei casi, l'identificazione biometrica è poco praticabile, soprattutto quando si parla di sicurezza delle applicazioni web, quindi nell'autenticazione a due fattori (two factor authentication, 2FA) si utilizza solitamente un secondo attributo: "ciò che possiedi". Una delle opzioni più popolari per questo secondo fattore è un token fisico, come :
Il token fisico è frequentemente utilizzato per l'autenticazione in VPN aziendali e servizi finanziari. Per autenticarsi nel servizio è necessario utilizzare sia la password, sia il codice sul token (che cambia spesso) insieme a un PIN. Teoricamente, per identificarsi, un attaccante dovrebbe conoscere la password, possedere il token e sapere anche il PIN del token. Nel caso di un reset della password, la password stessa è chiaramente sconosciuta, tuttavia il possesso del token può essere utilizzato per confermare la proprietà dell'account. Naturalmente, come per qualsiasi implementazione di sicurezza, , ma sicuramente aumenta la barriera all'ingresso.
Uno dei principali problemi di questo approccio è il costo e la logistica dell'implementazione; stiamo parlando della consegna di dispositivi fisici a ogni cliente e della formazione su questo nuovo processo. Inoltre, gli utenti devono avere con sé il dispositivo, il che nel caso di un token fisico non avviene sempre. Un'altra opzione è implementare un secondo fattore di autenticazione tramite SMS, che nel caso del 2FA può servire a confermare che la persona che sta effettuando il reset possiede il telefono cellulare del proprietario dell'account. Ecco come lo fa Google:
È anche necessario attivare , ma questo significa che al prossimo ripristino della password il tuo telefono cellulare potrebbe diventare il secondo fattore di autenticazione. Permettimi di dimostrarlo con il mio iPhone per motivi che diventeranno presto chiari:
Dopo aver identificato l'indirizzo email, Google determina che la 2FA è stata attivata e possiamo ripristinare l'account tramite una verifica che viene inviata tramite SMS al telefono cellulare del proprietario dell'account:
Ora dobbiamo scegliere di avviare il processo di ripristino:
Questa azione provoca l'invio di un'email all'indirizzo registrato:
Questa email contiene l'URL per il ripristino:
Accedendo all'URL di ripristino viene inviato un SMS e il sito web chiede di inserirlo:
Ecco questo SMS:
Dopo averlo inserito nel browser, torniamo alla zona del classico ripristino della password:
Probabilmente sembra un po' prolisso, ed è così, ma il modulo conferma che chi sta effettuando il ripristino ha accesso all'indirizzo email e al telefono cellulare del proprietario dell'account. Ma questo potrebbe essere nove volte più sicuro rispetto al ripristino della password solo tramite email. Tuttavia, ci sono dei problemi...
Il problema riguarda gli smartphone. Il dispositivo mostrato di seguito può autenticare solo un fattore di autenticazione: può ricevere SMS ma non email:
Tuttavia, questo dispositivo può ricevere SMS e ricevere email per il ripristino della password:
Il problema è che consideriamo l'email come il primo fattore di autenticazione e gli SMS (o persino un'app che genera token) come il secondo, ma oggi sono uniti in un unico dispositivo. Ovviamente ciò significa che se qualcun altro accede al tuo smartphone, tutta questa comodità si ridurrà a un solo canale; quel secondo fattore 'quello che hai' implica che hai anche il primo fattore. E tutto ciò è protetto da un PIN di quattro cifre... se il telefono ha effettivamente un PIN e è stato bloccato.
Sì, la funzione 2FA implementata da Google fornisce sicuramente una protezione aggiuntiva, ma non è protetta "dall'ignoranza" e non dipende affatto da due canali completamente autonomi.
Ripristino tramite nome utente contro ripristino tramite indirizzo email
È necessario consentire il ripristino solo tramite indirizzo e-mail? O l'utente dovrebbe avere la possibilità di effettuare il ripristino anche tramite nome? Il problema del ripristino tramite nome utente è che non c'è modo di informare l'utente riguardo a un nome utente errato, senza rivelare che qualcun altro potrebbe avere un account con quel nome. Nella sezione precedente, il ripristino tramite e-mail garantiva che il legittimo proprietario di quell'indirizzo e-mail ricevesse sempre un feedback senza rivelare pubblicamente la sua esistenza nel sistema. Con solo il nome utente, questo non è possibile.
Quindi la risposta è breve: solo e-mail. Se provi a effettuare il ripristino solo con il nome utente, ci saranno casi in cui l'utente non capirà cosa sia successo, o rivelando l'esistenza degli account. Sì, è solo un nome utente, non un indirizzo e-mail, e sì, chiunque può scegliere un qualsiasi nome utente (disponibile), ma c'è comunque una grande probabilità di rivelare indirettamente i proprietari degli account a causa della tendenza degli utenti a riutilizzare il nome.
Allora, cosa succede quando qualcuno dimentica il proprio nome utente? Se si presume che il nome utente non sia direttamente un indirizzo e-mail (cosa che accade spesso), il processo è simile a come inizia un ripristino della password: inseriamo l'indirizzo e-mail e poi inviamo un messaggio a quell'indirizzo, senza rivelarne l'esistenza. L'unica differenza è che questa volta il messaggio contiene solo il nome utente, non un URL di ripristino della password. O questo, o nell'e-mail sarà indicato che non c'è alcun account per quell'indirizzo.
Verifica dell'identità e accuratezza degli indirizzi e-mail
Un aspetto chiave del ripristino delle password, e probabilmente anche il più aspetto chiave è la verifica dell'identità della persona che sta tentando di eseguire il ripristino. È veramente il legittimo proprietario dell'account, o qualcuno sta cercando di hackerarlo o di creare disagio al proprietario?
È evidente che la posta elettronica è il canale più comodo e diffuso per la verifica dell'identità. Non è immune da utilizzi impropri (“da principianti”) e ci sono molti casi in cui la semplice possibilità di ricevere email all'indirizzo del proprietario dell'account non è sufficiente se è richiesta un'alta affidabilità nell'identificazione (da qui l'uso della 2FA), tuttavia è quasi sempre il punto di partenza del processo di reset.
Se la posta elettronica deve svolgere un ruolo nel garantire fiducia, la prima cosa da verificare è che l'indirizzo email sia realmente corretto. Se qualcuno commette un errore in un carattere, è evidente che il reset non avrà inizio. Il processo di verifica dell'email al momento della registrazione è un modo affidabile per controllare la correttezza dell'indirizzo. Tutti noi abbiamo visto questo in pratica: ci si registra, si riceve un'email con un URL unico su cui cliccare, che conferma che si è veramente il proprietario di quell'account email. L'impossibilità di accedere al sistema fino al completamento di questo processo garantisce la motivazione a confermare l'indirizzo.
Come in molti altri aspetti della sicurezza, questo modello riduce l'usabilità in cambio di un livello maggiore di sicurezza rispetto alla fiducia nell'identità dell'utente. Questo può essere accettabile per un sito la cui registrazione è altamente valutata dall'utente e che accetterà volentieri un ulteriore passo nel processo (servizi a pagamento, banking, ecc.), ma simili requisiti possono allontanare l'utente se percepisce l'account come 'usa e getta', utilizzandolo ad esempio semplicemente come mezzo per commentare un post.
Identificazione di chi ha avviato il processo di reset
È evidente che ci sono motivi per un uso malevolo della funzione di reset, e i malintenzionati possono sfruttarla in vari modi. Un trucco semplice che possiamo usare per confermare la fonte della richiesta (questo trucco di solito funziona) è quello di includere nell'email di proposta di reset l'indirizzo IP di chi richiede. Questo fornisce al destinatario alcune informazioni per identificare la fonte della richiesta.
Ecco un esempio dalla funzione di reset che sto attualmente integrando in ASafaWeb:
Il collegamento «find out more» («Scopri di più») porta l'utente al sito web , che comunica informazioni come la posizione e l'organizzazione della richiesta di reimpostazione:
Naturalmente, chiunque voglia nascondere la propria identità ha molti modi per offuscare il proprio vero IP, tuttavia questo è un modo conveniente per aggiungere un parziale identificativo della richiesta, e in maggior parte dei alcuni casi fornirà un'adeguata comprensione di chi effettua la richiesta di reimpostazione della password.
Notifica dei cambiamenti via email
Questo post è incentrato su un tema: la comunicazione; informa il proprietario dell'account il più possibile su cosa sta succedendo in ogni fase del processo, senza rivelare nulla che possa essere usato con intento malevolo. Lo stesso vale per la situazione in cui la password è stata effettivamente cambiata — informalo!
Le ragioni per cambiare la password possono essere due:
- Cambio della password dopo l'accesso, perché l'utente vuole una nuova password
- Reimpostazione della password senza accesso, perché l'utente l'ha dimenticata
Sebbene questo post sia principalmente dedicato alla reimpostazione, la notifica nel primo caso riduce il rischio che qualcuno cambi la password senza la conoscenza del legittimo proprietario. Come può succedere? Uno scenario comune è il recupero della password del legittimo proprietario (password riutilizzata, trapelata da un'altra fonte; password ottenuta tramite keylogging; password facilmente indovinabili, ecc.), dopo di che un malintenzionato decide di cambiarla, bloccando così il proprietario. Senza una notifica via email, il vero proprietario non saprà della modifica della password.
Certo, nel caso di reimpostazione della password, il proprietario dovrebbe già aver iniziato il processo (o bypassato i mezzi di verifica dell'identità sopra descritti), quindi il cambiamento non dovrebbe essere una sorpresa per lui, tuttavia la conferma via email sarà un feedback positivo e una verifica aggiuntiva. Inoltre, garantisce coerenza con lo scenario descritto sopra.
Oh, e nel caso in cui non sia già chiaro — non inviare la nuova password via email! A qualcuno questo potrebbe sembrare divertente, ma :
Log, log, log e ancora più log
La funzione di reset della password è attraente per i malintenzionati: l'attaccante può voler accedere all'account di un'altra persona o semplicemente creare disagi al proprietario dell'account/sistema. Molte delle pratiche descritte sopra permettono di ridurre la probabilità di abusi, ma non li prevengono e non impediranno sicuramente alle persone di cercare di utilizzare la funzione in modo non previsto.
Per riconoscere un comportamento malevolo, una pratica assolutamente preziosa è il logging, e intendo dire un logging molto dettagliato. Registra i tentativi di accesso falliti, il reset delle password, la modifica delle password (cioè quando l'utente è già connesso) e praticamente tutto ciò che può aiutarti a comprendere ciò che sta accadendo; sarà molto utile in futuro. Registra nei log anche singole parti del processo, ad esempio, una buona funzione di reset dovrebbe includere l'inizio del reset tramite il sito web (registra la richiesta e i tentativi di accesso per il reset con nome utente o email errati), registra la visita al sito web tramite l'URL di reset (inclusi i tentativi di utilizzo di un token non valido), e poi annota nei log l'esito o meno della risposta alla domanda segreta.
Quando parlo di logging, non intendo solo registrare il fatto che una pagina è stata caricata, ma raccogliere il maggior numero possibile di informazioni, se non è riservata. Ragazzi, per favore, non registrate nei log le password! Nei log è necessario registrare l'identità dell'utente autorizzato (sarà autorizzato se cambia una password esistente o tenta di resettare la password di qualcun altro dopo essersi connesso al sistema), qualunque nome utente o indirizzo email tentato e qualsiasi token di reset che sta cercando di utilizzare. È anche utile registrare nei log aspetti come gli indirizzi IP e, se possibile, anche le intestazioni delle richieste. Questo ti permette di ricostruire non solo cosa cosa sta tentando di fare l'utente (o l'attaccante), ma anche chi chi è.
Delegare la responsabilità ad altri esecutori
Se pensi che tutto ciò rappresenti un grande volume di lavoro, non sei solo. In realtà, costruire un sistema affidabile per la gestione degli account non è un compito facile. Non si tratta solo di una difficoltà tecnica, ci sono molte peculiarità coinvolte. Non riguarda solo il reset, ma esiste un intero processo di registrazione, una memorizzazione sicura delle password, la gestione di molteplici tentativi di accesso non riusciti, ecc. e così via. Anche se , oltre a ciò c'è molto altro da fare.
Oggi ci sono molti fornitori esterni che si assumono volentieri tutte le difficoltà, astrarre tutto questo in un servizio gestito. Tra questi servizi ci sono OpenID, OAuth e anche Facebook. Alcune persone (OpenID si è rivelato molto successo su Stack Overflow), tuttavia altri .
Senza dubbio, un servizio come OpenID risolve molti problemi per gli sviluppatori, ma è altrettanto certo che introduce nuovi problemi. Hanno un ruolo? Sì, ma è evidente che non osserviamo un uso massiccio dei servizi dei fornitori di autenticazione. Le banche, le compagnie aeree e persino i negozi — tutti implementano i propri meccanismi di autenticazione, e chiaramente ci sono motivi molto validi per questo.
Reset malevolo
Un aspetto importante di ciascuno degli esempi sopra menzionati è che la vecchia password è considerata inutile solo dopo la conferma dell'identità del proprietario dell'account. Questo è importante, perché se un account potesse essere resettato fino a senza verifica dell'identità, questo permetterebbe una serie di azioni malevole.
Ecco un esempio: qualcuno partecipa a un'asta in un sito di aste, e verso la fine del processo di asta blocca i concorrenti avviando il processo di reset, in questo modo eliminandoli dall'asta. È evidente che se una funzione di reset mal progettata può essere sfruttata in modo errato, può portare a gravi conseguenze negative. Vale la pena notare che il blocco degli account tramite tentativi di accesso errati è una situazione simile, ma questa è già un'altra questione.
Come ho detto prima, se si consente agli utenti anonimi di reimpostare la password di qualsiasi account, semplicemente conoscendo il suo indirizzo email, si crea una situazione perfetta per un attacco di tipo "denial of service". Questo non è necessariamente quello di cui siamo abituati a parlare, ma non c'è modo più veloce per bloccare l'accesso a un account rispetto a una funzione di reimpostazione password mal concepita. , di cui normalmente parliamo, ma non c'è modo più veloce per bloccare l'accesso a un account rispetto a una funzione di reimpostazione password mal concepita.
Il punto più debole
Dal punto di vista della protezione di un singolo account, tutto ciò che è scritto sopra è fantastico, ma devi sempre tenere a mente l'ecosistema che circonda l'account che stai proteggendo. Permettimi di fare un esempio:
ASafaWeb è ospitato su un servizio straordinario fornito da AppHarbor. Il processo di reimpostazione dell'account di hosting avviene così:
Fase 1:
Fase 2:
Fase 3:
Fase 4:
Dopo aver letto tutte le informazioni precedenti, è già facile capire quali aspetti in un mondo ideale realizzeremmo in modo diverso. Tuttavia, qui voglio dire che se pubblicassi un sito simile a ASafaWeb sul servizio di AppHarbor, e poi inventassi ottime domande segrete e risposte, aggiungessi un secondo fattore di autenticazione e facessi tutto il resto secondo le regole, non annulla il fatto che il punto più debole dell'intero processo sarà in grado di rompere tutto questo. Se qualcuno riesce a autenticarsi con successo su AppHarbor, utilizzando le mie informazioni, potrà cambiare la password di qualsiasi account ASafaWeb a suo piacimento!
Il significato è che la resilienza dell'attuazione della sicurezza deve essere considerata nel suo insieme: è necessario modellare le minacce a ciascun punto di ingresso del sistema, anche se si tratta di un processo superficiale, ad esempio l'accesso al sistema di AppHarbor. Questo dovrebbe darmi una buona idea di quanta energia devo investire nel processo di reimpostazione della password di ASafaWeb.
Mettiamo tutto insieme
Questo post contiene una grande quantità di informazioni, quindi voglio concentrarlo in uno schema visivo semplice:
Ricorda di eseguire la registrazione dettagliata di ciascuno di questi punti. Ecco tutto, è così semplice!
Conclusioni
Il mio post sembra completo, tuttavia ci sono molti materiali aggiuntivi che io essere. includere in esso, ma ho deciso di distaccarmene per brevità: il ruolo dell'indirizzo email di recupero, la situazione in cui si perde accesso all'email associata all'account (ad esempio, se si lascia un lavoro) e così via. Come ho detto in precedenza, la funzione di reset non è così complessa, ci sono solo molti punti di vista su di essa.
Anche se il reset non è così difficile, spesso viene implementato in modo errato. In precedenza abbiamo visto un paio di esempi in cui l'implementazione può ha portato a problemi, e ci sono molti più precedenti in cui un reset errato in effetti problemi. Recentemente è emerso che . Questo è un serio risultato negativo!
Pertanto, prestare attenzione alle proprie funzioni di reset, in vari punti, e durante la progettazione della funzione non toglierti il tuo cappello nero, perché c'è una grande probabilità che qualcun altro lo indossi!
In base alla pubblicità
VDSina offre opzioni economiche con pagamento giornaliero, ogni server è connesso a un canale Internet da 500 Megabit e protetto gratuitamente da attacchi DDoS!
Fonte: habr.com
