Autenticazione a due fattori
Quanto hai letto riguarda l'identificazione basata su ciò che sa chi fa la richiesta. Sa il suo indirizzo email, sa come accedervi (cioè sa la sua password) e conosce le risposte alle domande segrete.
La «conoscenza» è considerata un fattore di autenticazione; gli altri due fattori comuni sono ciò che hai, come un dispositivo fisico, e ciò che sei, come le impronte digitali o la retina dell'occhio.
Nella maggior parte dei casi, l'identificazione biometrica è poco praticabile, specialmente quando si parla di sicurezza delle applicazioni web, quindi nell'autenticazione a due fattori (two-factor authentication, 2FA) si utilizza di solito il secondo attributo - «ciò che hai». Una delle opzioni più popolari per questo secondo fattore è un token fisico, ad esempio, :
Il token fisico è frequentemente utilizzato per l'autenticazione in VPN aziendali e nei servizi finanziari. Per accedere al servizio è necessario utilizzare sia una password che il codice del token (che cambia frequentemente) insieme a un PIN. Teoricamente, per identificarsi, un attaccante dovrebbe conoscere la password, avere il token e anche conoscere il PIN del token. In uno scenario di reset della password, la password stessa è ovviamente sconosciuta, ma possedere il token può essere utilizzato per confermare la titolarità dell'account. Naturalmente, come in qualsiasi implementazione di sicurezza, , ma aumenta sicuramente la barriera d'ingresso.
Uno dei principali problemi di questo approccio è il costo e la logistica della sua attuazione; stiamo parlando della consegna di dispositivi fisici a ogni cliente e della formazione su un nuovo processo. Inoltre, gli utenti devono avere con sé il dispositivo, il che non è sempre possibile nel caso di un token fisico. Un'altra opzione è implementare il secondo fattore di autenticazione tramite SMS, che nel caso della 2FA può servire come conferma che la persona che esegue il processo di reset possiede il cellulare del titolare dell'account. Ecco come lo fa Google:
È anche necessario includere , ma questo significa che durante il prossimo reset della password il tuo telefono cellulare potrebbe diventare il secondo fattore di autenticazione. Lasciate che vi mostri questo esempio sul mio iPhone per motivi che diventeranno chiari tra poco:
Dopo aver identificato l'indirizzo email dell'account Google, si determina che la 2FA è stata attivata e possiamo reimpostare l'account tramite una verifica che viene inviata via SMS al cellulare del titolare dell'account:
Ora dobbiamo scegliere l'inizio del processo di reset:
Questa azione comporta l'invio di un'email all'indirizzo registrato:
Questa email contiene l'URL per il reset:
Quando si accede all'URL per il reset, viene inviato un SMS e il sito web chiede di inserirlo:
Ecco l'SMS:
Dopo averlo inserito nel browser, torniamo all'area classica per il reset della password:
Probabilmente sembra un po' verboso, ed è così, ma il modulo conferma che la persona che esegue il reset ha accesso all'indirizzo email e al numero di telefono mobile del proprietario dell'account. Tuttavia, questo può essere fino a nove volte più sicuro rispetto al reset della password solo tramite email. Ma ci sono delle problematiche...
Il problema riguarda gli smartphone. Il dispositivo mostrato qui 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 reset della password:
Il problema è che consideriamo l'email come il primo fattore di autenticazione e gli SMS (o anche le app che generano token) come il secondo, ma oggi sono uniti in un unico dispositivo. Ciò implica che se qualcuno ottiene accesso al tuo smartphone, tutta questa comodità diventa un ritorno a un singolo canale; questo secondo fattore 'qualcosa che hai' implica che hai anche il primo fattore. E tutto ciò è protetto da un PIN di quattro cifre… se il telefono ha un PIN. e è stato bloccato.
Sì, la funzione di autenticazione a due fattori (2FA) implementata da Google offre sicuramente una protezione aggiuntiva, ma non è protetta 'dai meno esperti' e non dipende affatto da due canali completamente autonomi.
Reset tramite nome utente contro reset tramite indirizzo email
Dovrebbe essere consentito il reset solo tramite indirizzo email? O l'utente dovrebbe avere la possibilità di effettuare il reset anche tramite nome utente? Il problema del reset tramite nome utente è che non c'è modo di informare l'utente su un nome utente errato, senza rivelare che qualcun altro possa avere un account con questo nome. Nella sezione precedente, il ripristino tramite email ha garantito che il legittimo proprietario di questa email riceva sempre feedback senza la divulgazione pubblica della sua esistenza nel sistema. Con solo il nome utente non è possibile farlo.
Pertanto, la risposta è semplice: solo email. Se provi a eseguire il ripristino solo usando il nome utente, potrebbero verificarsi situazioni in cui l'utente si chiederà cosa sia successo. o stai rivelando l'esistenza degli account. Sì, è solo un nome utente, non un indirizzo email e sì, chiunque può scegliere 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 i nomi.
Cosa succede quindi quando qualcuno dimentica il proprio nome utente? Se si considera che il nome utente non è immediatamente un indirizzo email (cosa che accade spessissimo), il processo è simile a quello di un reset della password: inseriamo l'indirizzo email e poi inviamo un messaggio a tale indirizzo, senza rivelarne l'esistenza. L'unica differenza è che questa volta il messaggio contiene solo il nome utente, e non un URL per il reset della password. Oppure, nell'email sarà indicato che non esiste un account per quell'indirizzo.
Verifica dell'identità e accuratezza degli indirizzi email
Un aspetto cruciale del reset delle password, e probabilmente il più cruciale aspetto è la verifica dell'identità della persona che sta tentando di effettuare il reset. È davvero il legittimo proprietario dell'account, o qualcuno sta tentando di hackerarlo o creare disagi al proprietario?
È evidente che l'e-mail sia il canale più comodo e comune per la verifica dell'identità. Non è immune da malintesi e ci sono molti casi in cui la semplice possibilità di ricevere e-mail all'indirizzo del proprietario dell'account non è sufficiente se è richiesta un'alta affidabilità nell'identificazione (ed è per questo che si utilizza la 2FA). Tuttavia, quasi sempre rappresenta il punto di partenza per il processo di reimpostazione.
Se l'e-mail deve svolgere un ruolo nella garanzia dell'affidabilità, è fondamentale assicurarsi prima di tutto che l'indirizzo e-mail sia corretto. Se qualcuno commette un errore di battitura, è chiaro che la reimpostazione non inizierà. Il processo di verifica dell'e-mail durante la registrazione è un metodo sicuro per controllare la validità dell'indirizzo. Tutti noi l'abbiamo visto in pratica: ti registri e ricevi un'e-mail con un URL unico su cui devi cliccare, confermando così che sei davvero il proprietario di quell'account e-mail. L'impossibilità di accedere al sistema fino al completamento di questo processo garantisce una motivazione per confermare l'indirizzo.
Come in molti altri aspetti della sicurezza, questo modello riduce l'usabilità in cambio di una maggiore sicurezza in relazione alla verifica dell'identità dell'utente. Questo può essere accettabile per un sito a cui l'utente attribuisce un alto valore e che con piacere accetterebbe un ulteriore passaggio nel processo (servizi a pagamento, banking, ecc.), ma simili misure possono allontanare l'utente se percepisce l'account come 'usa e getta' e lo usa, ad esempio, semplicemente per commentare un post.
Identificazione di chi ha avviato il processo di reset
È chiaro che ci sono motivi per un uso dannoso della funzione di reset, e i malintenzionati possono sfruttarla in diversi modi. Un semplice trucco che possiamo utilizzare per confermare la fonte della richiesta (questo trucco di solito funziona) è quello di aggiungere all'e-mail che offre il reset l'indirizzo IP del richiedente. 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 link «find out more» («Scoprire di più») porta l'utente al sito , fornendo informazioni come la posizione e l'organizzazione della richiesta di reset:
Naturalmente, chiunque desideri nascondere la propria identità ha numerosi modi per offuscare il proprio vero indirizzo IP, tuttavia questo è un modo conveniente per fornire un parziale identificativo della richiesta e, in nella maggior parte alcuni casi, ti darà un'idea sufficiente di chi sta effettuando la richiesta per il reset della password.
Notifica di cambiamenti via email
Questo post è intriso di un tema — comunicazione; fornisci al proprietario dell'account quante più informazioni possibile su ciò che sta accadendo in ogni fase del processo, senza rivelare nulla che possa essere utilizzato male. Lo stesso vale anche per la situazione in cui la password è stata effettivamente cambiata — informa il proprietario!
Le ragioni per cui una password può essere cambiata possono essere due:
- Cambio password dopo il login, perché l'utente desidera una nuova password
- Reset della password senza login, perché l'utente l'ha dimenticata
Sebbene questo post sia principalmente dedicato al ripristino della password, la notifica nel primo caso riduce il rischio che qualcuno modifichi la password senza il consenso del legittimo proprietario. Come può accadere? Uno scenario molto comune è il recupero della password del legittimo proprietario (una password riutilizzata, trapelata da un'altra fonte; una password ottenuta tramite keylogging; una password facile da indovinare, ecc.), dopo di che l'attaccante decide di cambiarla, bloccando così il proprietario. Senza una notifica via email, il vero proprietario non sarà a conoscenza della modifica della password.
Certo, nel caso di un ripristino della password, il proprietario dovrebbe già aver avviato il processo (o aver eluso i mezzi di verifica dell'identità sopra descritti), quindi il cambiamento non dovrebbe potrebbe essere una sorpresa per lui, tuttavia la conferma via email sarebbe un riscontro positivo e una verifica aggiuntiva. Inoltre, questo garantisce coerenza con lo scenario descritto precedentemente.
Oh, e nel caso in cui non sia già ovvio — 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 è allettante per gli aggressori: un attaccante desidera ottenere accesso all'account di un'altra persona o semplicemente arrecare fastidio al proprietario dell'account/sistema. Molte delle pratiche sopra descritte riducono la probabilità di abusi, ma non li prevengono e sicuramente non impediranno alle persone di tentare di utilizzare la funzione in modo non autorizzato.
Per riconoscere comportamenti malevoli, 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à loggato) e praticamente tutto ciò che può aiutarti a comprendere cosa sta accadendo; sarà molto utile in futuro. Registra nei log anche singole parti Il processo, ad esempio, una buona funzione di reset dovrebbe includere l'inizio del reset tramite il sito web (registrare la richiesta e i tentativi di accesso per il reset con nome utente o email errati), registrare la visita al sito web all'URL di reset (comprese le tentativi di utilizzo di un token errato) e poi registrare nel log il successo o l'errore nella risposta alla domanda segreta.
Quando parlo di logging, intendo non solo registrare il fatto di aver caricato la pagina, ma anche raccogliere quante più informazioni possibile, se non sono riservate. Ragazzi, per favore, non registrate le password nei log! Nei log bisogna registrare l'identità dell'utente autenticato (sarà autenticato se egli cambia una password esistente o cerca di resettare una password di qualcun altro dopo aver effettuato il login), qualsiasi nome utente o indirizzo email provato da lui, più qualsiasi token di reset che sta cercando di utilizzare. Ma è anche utile registrare nei log aspetti come gli indirizzi IP e, se possibile, anche gli header delle richieste. Questo permette di ricreare non solo cosa l'utente (o l'attaccante) cerca di fare, ma anche chi è così.
Delegare responsabilità ad altri esecutori
Se pensi che tutto ciò rappresenti un enorme onere di lavoro, non sei solo. In realtà, costruire un sistema affidabile per la gestione degli account è una sfida complessa. Non si tratta solo di difficoltà tecniche, ma ci sono molte peculiarità. Non si limita al reset, esiste un intero processo di registrazione, una conservazione sicura delle password, la gestione di molteplici tentativi di accesso errati, ecc. e così via. Anche se , oltre a questo ci sono molte altre cose da fare.
Oggi ci sono molti fornitori esterni che si assumono volentieri tutte queste difficoltà e astraendo tutto ciò in un unico servizio gestito. Tra questi servizi ci sono OpenID, OAuth e persino Facebook. Alcune persone (OpenID si è rivelato molto efficace su Stack Overflow), tuttavia altri .
Senza dubbio, un servizio come OpenID risolve molti problemi per gli sviluppatori, ma è altresì certo che aggiunge nuove complessità. Hanno un ruolo? Sì, ma è evidente che non vediamo un uso massiccio dei servizi offerti dai fornitori di autenticazione. Banche, compagnie aeree e persino negozi — tutti implementano i propri meccanismi di autenticazione, e ovviamente ci sono motivi molto validi per questo.
Reset dannoso
Un aspetto importante di ciascuno degli esempi sopra citati è che la vecchia password è considerata inutile solo dopo la verifica dell'identità del proprietario dell'account. Questo è importante, perché se l'account potesse essere resettato fino a senza la verifica dell'identità, si aprirebbero possibilità per ogni tipo di azione malevola.
Ecco un esempio: qualcuno partecipa a un'asta su un sito d'aste e, verso la fine del processo, blocca i concorrenti avviando un processo di reset, eliminandoli così dall'asta. È evidente che se una funzione di reset mal progettata può essere sfruttata in modo errato, ciò può portare a seri risultati negativi. È importante notare che il blocco degli account tramite tentativi di accesso errati è una situazione simile, ma questa è un'altra storia.
Come ho detto prima, se si dà agli utenti anonimi la possibilità di resettare la password di qualsiasi account semplicemente conoscendo l'indirizzo email, si crea una situazione ideale per un attacco di tipo "denial of service". Potrebbe non essere quello di cui siamo abituati a parlare, ma non esiste modo più veloce per bloccare l'accesso a un account che con una funzione di reset della password mal progettata. , di cui parliamo generalmente, ma non esiste modo più veloce per bloccare l'accesso a un account che tramite una funzione di reset della password mal progettata.
Il punto più debole
Dal punto di vista della sicurezza di un account, tutto ciò che è stato detto sopra è fantastico, ma bisogna sempre tenere a mente l'ecosistema che circonda l'account che si vuole proteggere. Permettetemi di fare un esempio:
ASafaWeb è ospitato su un servizio straordinario fornito da AppHarbor. Il processo di reimpostazione dell'account di hosting avviene in questo modo:
Fase 1:
Fase 2:
Fase 3:
Fase 4:
Dopo aver letto tutte le informazioni precedenti, è facile capire quali aspetti in un mondo ideale realizzeremmo diversamente. Tuttavia, voglio dire che se pubblicassi un sito simile a ASafaWeb sul servizio AppHarbor, e poi inventassi ottime domande e risposte segrete, aggiungessi un secondo fattore di autenticazione e facessi tutto il resto seguendo le regole, questo non annullerebbe il fatto che il punto più debole dell'intero processo potrebbe romperlo. Se qualcuno riesce a effettuare l'autenticazione in AppHarbor utilizzando le mie informazioni, potrebbe cambiare la password di qualsiasi account ASafaWeb a suo piacimento!
Il concetto è che la resilienza della protezione deve essere vista in modo olistico: bisogna modellare le minacce per ogni punto di ingresso del sistema, anche se si tratta di un processo superficiale, come l'accesso al sistema AppHarbor. Questo dovrebbe darmi una buona idea di quanti sforzi devo dedicare al processo di reimpostazione della password di ASafaWeb.
Colleghiamo tutto insieme
Questo post contiene una grande quantità di informazioni, quindi voglio concentrarle in uno schema visivo semplice:
Ricordate di eseguire il logging il più dettagliato possibile su ciascuno di questi punti. Ecco tutto, è semplice!
Risultati
Il mio post sembra completo, tuttavia ci sono molti materiali aggiuntivi che voglio potrebbe includere, ma ho deciso di omettere per brevità: il ruolo dell'indirizzo e-mail di recupero, la situazione in cui si perde l'accesso all'e-mail collegata all'account (ad esempio, se si è licenziati) e così via. Come ho detto prima, la funzione di reset non è così complicata, ci sono solo molteplici 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 causato problemi, e ci sono molti più casi in cui un reset errato davvero ha portato a problemi. Recentemente è emerso che Questo è un grave risultato negativo!
Quindi, siate cauti con le vostre funzioni di reset, in diversi punti, e quando progettate le funzioni, non togliete il vostro cappello nero, perché c'è una grande possibilità che qualcun altro lo indossi!
In pubblicità
VDSina offre soluzioni economiche con pagamento giornaliero, ogni server è collegato a un canale internet di 500 Megabit ed è protetto gratuitamente da attacchi DDoS!
Fonte: habr.com
