Autenticazione a due fattori
Tutto quello che hai letto identificazione interessata sulla base di ciò il richiedente lo sa. Conosce il suo indirizzo e-mail, sa come accedervi (ovvero conosce la sua password e-mail) e conosce le risposte alle sue domande di sicurezza.
La "conoscenza" è considerata un fattore di autenticazione; altri due fattori comuni sono cos'hai, come un dispositivo fisico, e chi sei, ad esempio, impronte digitali o retina.
Nella maggior parte dei casi, eseguire l'identificazione biologica non è fattibile, soprattutto quando si parla di sicurezza delle applicazioni web, quindi l'autenticazione a due fattori (2FA) utilizza solitamente il secondo attributo: "quello che hai". Una variante popolare di questo secondo fattore è un token fisico, ad es. :
Il token fisico viene spesso utilizzato per l'autenticazione nelle VPN aziendali e nei servizi finanziari. Per autenticarsi al servizio è necessario utilizzare sia una password che un codice sul token (che cambia frequentemente) in combinazione con un PIN. Teoricamente, per l'identificazione, un utente malintenzionato deve conoscere la password, possedere un token e conoscere anche il PIN del token. In uno scenario di reimpostazione della password, la password stessa è ovviamente sconosciuta, ma il possesso del token può essere utilizzato per dimostrare la proprietà dell'account. Naturalmente, come per qualsiasi implementazione di sicurezza, , ma alza sicuramente la barriera all’ingresso.
Uno dei principali problemi di questo approccio è il costo e la logistica dell’implementazione; stiamo parlando di consegnare dispositivi fisici a ciascun cliente e insegnargli il nuovo processo. Inoltre, gli utenti devono avere con sé il dispositivo, cosa che non sempre avviene con un token fisico. Un'altra opzione è implementare un secondo fattore di autenticazione tramite SMS, che nel caso della 2FA può servire come conferma che la persona che esegue il processo di ripristino possiede il telefono cellulare del proprietario dell'account. Ecco come fa Google:
È inoltre necessario abilitare , ma ciò significa che la prossima volta che reimposterai la password, il tuo telefono cellulare potrebbe diventare un secondo fattore di autenticazione. Permettimi di dimostrarlo utilizzando il mio iPhone per ragioni che diventeranno presto chiare:
Dopo aver identificato l'indirizzo email dell'account, Google determina che la 2FA è stata abilitata e possiamo reimpostare l'account utilizzando la verifica, che viene inviata tramite SMS al cellulare del proprietario dell'account:
Ora dobbiamo scegliere di avviare il processo di ripristino:
Questa azione provoca l'invio di un'e-mail all'indirizzo registrato:
Questa email contiene l'URL di reimpostazione:
Quando accedi all'URL di ripristino, viene inviato un SMS e il sito Web ti chiede di inserirlo:
Questo è l'SMS:
Dopo averlo inserito nel browser, torniamo al classico territorio di reimpostazione della password:
Probabilmente sembra un po' prolisso, e lo è, ma il modulo conferma che la persona che esegue il ripristino ha accesso all'indirizzo email e al telefono cellulare del proprietario dell'account. Ma può essere nove volte più sicuro che reimpostare la password solo tramite e-mail. Ci sono però dei problemi...
Il problema è legato agli smartphone. Il dispositivo mostrato di seguito può autenticarsi solo con un fattore di autenticazione: è in grado di ricevere SMS, ma non e-mail:
Tuttavia, questo dispositivo può ricevere SMS и ricevere email per la reimpostazione della password:
Il problema è che consideriamo l’e-mail come il primo fattore di autenticazione e gli SMS (o anche un’app per la generazione di token) come il secondo, ma oggi sono combinati in un unico dispositivo. Naturalmente, questo significa che se qualcuno mettesse le mani sul vostro smartphone, tutta questa comodità si ridurrebbe al fatto che saremo di nuovo su un canale; questo secondo fattore “questo, quello che hai” significa che hai anche il primo fattore. E tutto questo è protetto da un PIN di quattro cifre... sempre che il telefono abbia un PIN и era bloccato.
Sì, la funzionalità 2FA implementata da Google fornisce sicuramente una protezione aggiuntiva, ma non è infallibile, e di certo non dipende da due canali completamente autonomi.
Reimposta per nome utente o reimposta per indirizzo email
Devo consentire i ripristini solo tramite indirizzo email? Oppure l'utente dovrebbe essere in grado di reimpostare anche per nome? Il problema con la reimpostazione tramite nome utente è che non è possibile avvisare l'utente che il nome utente non è corretto. senza rivelare che qualcun altro potrebbe avere un account con questo nome. Nella sezione precedente, il ripristino dell'e-mail garantiva che il legittimo proprietario di quell'e-mail ricevesse sempre un feedback senza rivelarne pubblicamente l'esistenza nel sistema. Questo non può essere fatto utilizzando solo il nome utente.
Quindi la risposta è breve: solo email. Se provi a eseguire un ripristino utilizzando solo il nome utente, ci saranno casi in cui l'utente si chiederà cosa è successo, o rivelerai l'esistenza dei conti. Sì, è solo un nome utente, non un indirizzo email, e sì, chiunque può scegliere qualsiasi nome utente (disponibile), ma c'è comunque una buona possibilità che tu riveli indirettamente i proprietari degli account a causa della tendenza degli utenti a riutilizzare il nome.
Quindi cosa succede quando qualcuno dimentica il proprio nome utente? Supponendo che il nome utente non sia immediatamente un indirizzo email (come spesso accade), il processo è simile a come inizia la reimpostazione della password: inserendo un indirizzo email e quindi inviando un messaggio a quell'indirizzo senza rivelarne l'esistenza. L'unica differenza è che questa volta il messaggio contiene solo il nome utente e non l'URL di reimpostazione della password. Oppure l'e-mail dirà che non esiste un account per questo indirizzo.
Verifica dell'identità e accuratezza dell'indirizzo e-mail
Un aspetto chiave della reimpostazione della password, e forse anche più l'aspetto fondamentale è verificare l'identità della persona che tenta il ripristino. Si tratta effettivamente del legittimo proprietario dell'account o qualcuno sta cercando di hackerarlo o di arrecare disturbo al proprietario?
Ovviamente, l’e-mail è il canale più conveniente e più comune per la verifica dell’identità. Non è infallibile e ci sono molti casi in cui la semplice possibilità di ricevere e-mail all'indirizzo del proprietario dell'account non è sufficiente se è richiesto un elevato grado di sicurezza nell'identificazione (motivo per cui viene utilizzato 2FA), ma è quasi sempre la soluzione processo di ripristino del punto di partenza.
Se l'e-mail avrà un ruolo nel fornire garanzie, il primo passo è garantire che l'indirizzo e-mail sia effettivamente corretto. Se qualcuno ha inserito il simbolo sbagliato, ovviamente il ripristino non verrà avviato. Il processo di verifica dell'e-mail al momento della registrazione è un modo affidabile per verificare la correttezza dell'indirizzo. L'abbiamo visto tutti in pratica: ti iscrivi, ti inviano un'e-mail con un URL univoco su cui fai clic, il che conferma che sei effettivamente il proprietario di quell'account e-mail. Non poter accedere fino al completamento di questo processo ti garantisce di essere motivato a verificare il tuo indirizzo.
Come per molti altri aspetti della sicurezza, questo modello compromette l'usabilità in cambio di una maggiore sicurezza relativa alla fiducia nell'identità dell'utente. Ciò può essere accettabile per un sito in cui l'utente apprezza molto la registrazione e aggiungerebbe volentieri un altro passaggio nel processo (servizi a pagamento, servizi bancari, ecc.), ma tali cose potrebbero scoraggiare l'utente se percepisce l'account come "usa e getta" ” e utilizza , ad esempio, semplicemente come mezzo per commentare un post.
Identificazione di chi ha avviato il processo di ripristino
Ovviamente ci sono ragioni per un utilizzo dannoso della funzione di ripristino e gli aggressori possono utilizzarla in molti modi diversi. Un semplice trucco che possiamo usare per verificare l'origine di una richiesta (questo trucco solitamente funziona) - questo viene aggiunto a una lettera in cui si offre di reimpostare l'indirizzo IP del richiedente. Fornisce il destinatario alcuni informazioni per identificare la fonte della richiesta.
Ecco un esempio della funzione di ripristino che sto attualmente integrando in ASafaWeb:
Il collegamento “scopri di più” porta l'utente al sito , riportando informazioni quali la posizione e l'organizzazione di chi ha richiesto il ripristino:
Naturalmente, chiunque voglia nascondere la propria identità ha molti modi per offuscare il proprio vero indirizzo IP, ma questo è un modo conveniente per aggiungere un'identificazione parziale del richiedente e più casi, questo ti darà una buona idea di chi completerà la richiesta di reimpostazione della password.
Notifica delle modifiche tramite e-mail
Questo post è intriso di un tema: la comunicazione; Informa il più possibile il proprietario dell'account su ciò che sta accadendo in ogni fase del processo, senza rivelare nulla che possa essere utilizzato in modo dannoso. Lo stesso vale nel caso in cui la password sia effettivamente cambiata: segnalalo al proprietario!
Ci possono essere due motivi per cambiare la password:
- Modifica della password dopo l'accesso perché l'utente desidera una nuova password
- Reimpostare una password senza accedere perché l'utente l'ha dimenticata
Sebbene questo post riguardi principalmente il ripristino, la notifica del primo riduce il rischio che qualcuno modifichi la password all'insaputa del legittimo proprietario. Come può succedere? Uno scenario molto comune è che venga ottenuta la password del legittimo proprietario (una password riutilizzata trapelata da un'altra fonte, una password registrata con keylog, una password facile da indovinare, ecc.) e poi l'aggressore decida di cambiarla, bloccando così l'accesso al proprietario. . Senza notifica via email, il vero proprietario non verrà a conoscenza della modifica della password.
Naturalmente, in caso di reimpostazione della password, il proprietario avrebbe già avviato il processo da solo (o avrebbe aggirato i controlli di identificazione sopra descritti), quindi la modifica non dovrebbe potrebbe essere una sorpresa per lui, ma un'e-mail di conferma costituirà un feedback positivo e un'ulteriore verifica. Fornisce inoltre coerenza con lo scenario precedente.
Oh, e nel caso non fosse già ovvio... Non inviare una nuova password via mail! Questo potrebbe far ridere alcune persone, ma :
Registri, registri, registri e ancora registri
La funzione di reimpostazione della password è interessante per gli aggressori: l’aggressore vuole ottenere l’accesso all’account di un’altra persona o semplicemente causare disagi al proprietario dell’account/sistema. Molte delle pratiche sopra descritte riducono la probabilità di abusi, ma non li prevengono, e certamente non impediranno alle persone di tentare di utilizzare la funzionalità in modi non desiderati.
Per riconoscere comportamenti dannosi, la registrazione è una pratica assolutamente preziosa, e intendo dire registrazione molto dettagliata. Registra i tentativi di accesso falliti, le reimpostazioni delle password, le modifiche delle password (ad esempio quando l'utente ha già effettuato l'accesso) e quasi tutto ciò che può aiutarti a capire cosa sta succedendo; questo sarà molto utile in futuro. Log anche individuale parti di processo, ad esempio, una buona funzionalità di ripristino dovrebbe includere l'avvio di un ripristino tramite un sito Web (acquisire la richiesta di ripristino e i tentativi di accesso con un nome utente o un'e-mail errati), acquisire le visite al sito Web nell'URL di ripristino (compresi i tentativi di utilizzare un token errato), e quindi registrare l'esito positivo o negativo della risposta alla domanda di sicurezza.
Quando parlo di logging non intendo solo registrare il fatto che una pagina viene caricata, ma anche raccogliere quante più informazioni possibili, se non è confidenziale. Ragazzi, per favore non scrivere password nei log! I log devono registrare l'identità dell'utente autorizzato (sarà autorizzato se cambia il password esistente o tentativo di reimpostazione la password di qualcun altro dopo aver effettuato l'accesso), eventuali nomi utente o indirizzi e-mail tentati, oltre a eventuali token di ripristino tentati. Ma vale anche la pena registrare elementi come gli indirizzi IP e, se possibile, anche le intestazioni delle richieste. Ciò ti consente di ricreare non solo che l'utente (o l'aggressore) sta cercando di fare, ma anche che lui è un tale.
Delega di responsabilità ad altri artisti
Se pensi che tutto questo rappresenti un'enorme mole di lavoro, non sei il solo. In effetti, costruire un sistema di gestione degli account affidabile non è un compito facile. Non è che sia tecnicamente difficile, ha solo molte funzionalità. Non si tratta solo di reimpostare, c'è un intero processo di registrazione, archiviare in modo sicuro le password, gestire più tentativi di accesso falliti, ecc. Ecc. Sebbene , oltre a questo, c'è ancora molto da fare.
Oggi ci sono molti fornitori di terze parti felici di farsi carico di tutto il dolore e di astrarlo tutto in un unico servizio gestito. Tali servizi includono OpenID, OAuth e persino Facebook. Alcune persone (OpenID ha effettivamente avuto molto successo su Stack Overflow), ma altri .
Non c'è dubbio che un servizio come OpenID risolva molti problemi agli sviluppatori, ma senza dubbio ne aggiunge anche di nuovi. Hanno qualche ruolo? Sì, ma ovviamente non stiamo assistendo all’adozione di massa dei fornitori di servizi di autenticazione. Le banche, le compagnie aeree e persino i negozi implementano tutti il proprio meccanismo di autenticazione e ci sono ovviamente ottime ragioni per farlo.
Ripristino dannoso
Un aspetto importante di ciascuno degli esempi sopra riportati è che la vecchia password è considerata solo inutile dopo aver confermato l'identità del proprietario dell'account. Questo è importante perché se l'account potrebbe essere ripristinato a verifica dell’identificazione, ciò fornirebbe l’opportunità per tutti i tipi di azioni dannose.
Ecco un esempio: qualcuno sta facendo un'offerta su un sito di aste e, verso la fine del processo di offerta, blocca i concorrenti avviando un processo di ripristino, eliminandoli così dall'offerta. Ovviamente, se una funzione di ripristino mal progettata può essere utilizzata in modo improprio, ciò può portare a gravi risultati negativi. Vale la pena notare che i blocchi degli account dovuti a tentativi di accesso non validi sono una situazione simile, ma questo è un argomento per un altro post.
Come ho detto sopra, se dai agli utenti anonimi la possibilità di reimpostare la password di qualsiasi account semplicemente conoscendo il loro indirizzo email, allora questa è una situazione matura per un attacco di negazione del servizio. Questo potrebbe non essere quello giusto , di cui parlavamo, ma non esiste un modo più veloce per bloccare l'accesso a un account rispetto all'utilizzo di una funzione di reimpostazione della password mal progettata.
Il collegamento più debole
Dal punto di vista della protezione del singolo account, tutto quanto scritto sopra è ottimo, ma bisogna sempre essere consapevoli dell'ecosistema che circonda l'account che si sta proteggendo. Lasciate che vi faccia un esempio:
ASafaWeb è ospitato su uno straordinario servizio fornito da AppHarbor. Il processo di reimpostazione di un account di hosting procede in questo modo:
Fase 1:
Fase 2:
Fase 3:
Fase 4:
Dopo aver letto tutte le informazioni precedenti, è già facile capire quali aspetti in un mondo ideale implementeremmo in modo leggermente diverso. Tuttavia, quello che sto dicendo qui è che se pubblico un sito come ASafaWeb su AppHarbor e poi fornisco ottime domande e risposte sulla sicurezza, aggiungo un secondo fattore di autenticazione e faccio tutto il resto secondo le regole, allora questo non cambia il fatto che l’anello più debole dell’intero processo sarà capace di spezzarlo tutto. Se qualcuno si autentica con successo su AppHarbor utilizzando le mie informazioni, sarà in grado di cambiare la password di qualsiasi account ASafaWeb con quella di cui ha bisogno!
Il punto è che la forza di un’implementazione della sicurezza dovrebbe essere considerata in modo olistico: la minaccia di ogni punto di ingresso nel sistema deve essere modellata, anche se si tratta di un processo superficiale, come l’accesso al sistema AppHarbor. Questo dovrebbe darmi un'idea di quanto impegno devo impegnare nel processo di reimpostazione della password di ASafaWeb.
Mettere tutto insieme
Questo post contiene molte informazioni, quindi voglio condensarle in un semplice schema visivo:
Ricordatevi di effettuare una registrazione quanto più dettagliata possibile per ciascuno di questi elementi. Ecco, è semplice!
Risultati di
Il mio post sembra essere completo, tuttavia c'è molto materiale aggiuntivo che I potuto includere ma decidere di non includere per brevità: il ruolo di un indirizzo email di salvataggio, la situazione in cui perdi l'accesso all'email associata al tuo account (ad esempio, lasci il lavoro) e così via. Come ho detto prima, la funzione di ripristino non è così complicata, ma ci sono molti modi per vederla.
Anche se il ripristino non è così complicato, spesso viene implementato in modo errato. Sopra abbiamo visto un paio di esempi di quando l'implementazione может portare a problemi e ci sono molti altri precedenti in cui un ripristino errato davvero causato problemi. Recentemente si è scoperto che . Questo è un risultato negativo grave!
Quindi fai attenzione alle funzioni di ripristino, in diversi punti, e quando progettate una funzione, non toglietevi il cappello nero, perché ci sono buone probabilità che qualcun altro lo indossi!
Sui diritti della pubblicità
VDSina offre poco costoso con il pagamento giornaliero ogni server è connesso ad un canale Internet da 500 Megabit ed è protetto gratuitamente dagli attacchi DDoS!
Fonte: habr.com
