Domanda:
Reimpostazione della password fornendo indizi su possibili indirizzi e-mail validi
davshowhan449
2020-03-19 18:25:56 UTC
view on stackexchange narkive permalink

Abbiamo un sistema in cui se hai dimenticato la password e desideri reimpostarla, vai alla pagina della password dimenticata e inserisci il tuo indirizzo email. Verrà inviato un collegamento temporaneo alla tua email per reimpostare la password.

Ora, quando abbiamo sottoposto la nostra app a test di penetrazione, è stato rilevato un problema:

L'applicazione sta dando indizi di possibili indirizzi e-mail validi quando si tenta di reimpostare la password. Questa funzionalità può essere abusata semplicemente indovinando un possibile indirizzo email ed essendo in grado di trovarne di validi attraverso i messaggi di errore.

Bene, c'è solo un campo e ovviamente è ovvio che se reimpostare la password il tentativo fallisce, è dovuto a un'e-mail non valida. Sembra che questo test di penetrazione sia sbagliato. Esistono soluzioni per risolvere questo problema oltre all'aggiunta di un campo aggiuntivo (oltre all'email) per la reimpostazione della password?

è importante chiarire la differenza tra "email non valida" e "email non registrata" qui.se l'utente digita qualcosa che non corrisponde al formato di un indirizzo e-mail valido, ovviamente va bene dal punto di vista della sicurezza informarlo che il processo non è riuscito.se digitano un'e-mail valida che non è associata a un utente registrato, tuttavia, queste informazioni devono essere mantenute private.
Quale risposta date a un utente che utilizza un indirizzo email errato al momento del login?
@DocRoot: È buona norma rispondere con un messaggio generico come "Email o password non valida" (assumendo che si utilizzi la combinazione email + password come credenziali).
@bhorkarg Sì, lo so.Era inteso come un indizio / domanda retorica per l'OP.Se forniscono un messaggio "generico" (errore) a un tentativo di accesso non riuscito (come mi aspetterei, poiché è una pratica molto ben riconosciuta nell'interesse della sicurezza dell'account utente), perché fornire una risposta più "rivelatrice" in un'altra fasenel processo dell'account utente?
Sei risposte:
#1
+102
yoozer8
2020-03-19 18:35:05 UTC
view on stackexchange narkive permalink

Non indicare che il tentativo "non è riuscito". Un utente (legittimo o meno) chiede un link per la reimpostazione della password e ti fornisce un indirizzo email. Tutto quello che dovresti dire qui è sulla falsariga di

Le tue richieste sono state ricevute. Se disponiamo di un account corrispondente al tuo indirizzo email, riceverai un'email con un link per reimpostare la tua password.

L'utente riceverà comunque il link (successo), ma gli aggressori no sapere se un indirizzo email fornito è associato a un account.

Perché aggiungere anche la seconda frase?Basta fornire un generico "La tua richiesta è stata ricevuta e verrà elaborata".
Gli utenti legittimi a volte dimenticano quale indirizzo email hanno utilizzato, quindi è bello avvisarli che la richiesta potrebbe non andare a buon fine a causa di un account inesistente rispetto all'email contrassegnata come spam, ecc.
Inoltre, consente all'utente di sapere cosa aspettarsi.Sì, la maggior parte di noi ha già affrontato il processo e sa che dovremmo cercare un'e-mail.Ma per qualcuno che sta reimpostando una password per la prima volta, vuoi fargli sapere cosa aspettarsi che accada dopo.
Ma la stessa cosa si può scoprire provando la registrazione.A meno che tu non dica "anche la registrazione può o non può avere successo", il che mi sembra terribile.Tutto sommato, sembra che l'offuscamento sia facilmente aggirato a scapito dell'usabilità (se un utente digita erroneamente la sua e-mail, non lo scoprirà mai e aspetterà invano).
e se ci sono pagine che vengono dopo?come termini e condizioni, comunicazioni, FYI, annunci, sondaggi, ecc. prima dell'effettivo invio di e-mail?questo potrebbe influire sull'esperienza dell'utente.Un utente legittimo potrebbe dire, ho fatto tutto questo e alla fine non mi hanno detto che la mia email non era valida?
Queste pagine sono davvero necessarie però?Se dovessi completare un sondaggio, eliminare diversi annunci e leggere alcuni ToC prima di poter reimpostare la mia password, prenderei seriamente in considerazione se utilizzare quel servizio.Reimpostare la password dovrebbe essere semplice come scrivere il mio indirizzo e-mail e fare clic su un pulsante.
-1 Perché parli dell'implementazione più semplice senza nemmeno toccare il relativo modello di minaccia.Ad esempio, come sottolineato nei commenti, esporre le e-mail di utenti già registrati è una caratteristica tipica dei moduli di registrazione e la cosa importante è spesso prevenire la forzatura bruta mediante limitazione della velocità per IP.Né tocchi l'enorme successo alla UX e i pericoli di dare la stessa risposta (gli utenti reali vengono feriti più degli attori maligni)
@davshowhan449 Gli utenti dovrebbero accettare qualsiasi ToC al momento della registrazione, non durante l'uso
@Christoph "Prenderei seriamente in considerazione se utilizzare quel servizio" è un modo strano per scrivere "Eliminerei il mio account e non tornerò mai più"
Per la registrazione dell'account, è possibile evitare di rivelare tali informazioni se si rendono inaccessibili nuovi account senza verifica tramite posta elettronica.Nessuna di queste tecniche è difficile;è solo questione di decidere se l'esistenza dell'account è abbastanza segreta da giustificare un successo a UX.E, naturalmente, puoi mitigare i problemi di UX inviando un'e-mail anche in caso di errori (ad esempio, puoi inviare un'e-mail di "account non trovato" quando una reimpostazione della password non riesce).
In ogni caso, deve essere inviata un'e-mail all'indirizzo e-mail indicato.Se non è presente alcun account associato a tale indirizzo, informa il proprietario dell'account di posta elettronica che è stato effettuato un tentativo di reimpostazione della password.Se una terza parte ha tentato di reimpostare la password, sa che qualcuno la sta attaccando.Se hanno dimenticato quale indirizzo e-mail hanno utilizzato per la registrazione, non aspetteranno più l'e-mail o penseranno che il tuo sistema non funzioni, ma proveranno il loro prossimo indirizzo.
@UTF-8 Vuoi dire che un'e-mail deve essere inviata all'indirizzo indipendentemente dal fatto che sia registrato nel sistema o meno?Sembra discutibile.Sicuramente non vorrei ricevere e-mail da un servizio con cui non ho nulla a che fare solo perché qualcuno ha inserito il mio indirizzo e-mail in un modulo web.
@DavidZ Quindi controlliamo solo come i servizi popolari che tutti usiamo gestiscono questa situazione.Idk, forse SE?Quindi ho appena inserito un indirizzo e-mail non associato al mio account StackExchange nel modulo "Ho dimenticato la password".Cosa ho ricevuto?Un'email in cui si afferma: "Abbiamo ricevuto una richiesta di recupero dell'account su Meta Stack Exchange per [il mio indirizzo email secondario], ma quell'email non esiste nei nostri archivi".
@DavidMulder La mia preoccupazione con la limitazione della velocità per IP è che spesso blocca gli utenti VPN legittimi, anche questo un enorme successo per UX.
@Schwern Avere una piccola frazione di utenti che avrà un modulo di registrazione leggermente peggiore, ma comunque funzionante (dato che è stato programmato bene) non sembra un 'grande successo' (soprattutto rispetto all'alternativa: un processo di registrazione disgiunto in cui si riceveun'e-mail per continuare la registrazione).Ma sì, hai assolutamente ragione sul fatto che vale la pena considerare gli utenti VPN.
@DavidMulder Non è un grande successo finché non sei l'utente VPN che viene bloccato.Non so se hai letto le notizie di recente, ma stiamo per vedere molte più persone che lavorano da casa su VPN.:smorfia:
#2
+32
Demento
2020-03-19 18:34:12 UTC
view on stackexchange narkive permalink

La ragione di questo risultato è che un utente riceve risposte diverse, a seconda dell'esistenza dell'indirizzo email. Questo può essere semplice come dire loro che l'indirizzo non è noto o qualcosa di più sottile nella risposta.

L'implementazione più semplice per evitare questo tipo di problema è restituire la stessa identica risposta , indipendentemente dal fatto che l'indirizzo e-mail esista o meno. Un semplice

Le informazioni per reimpostare la password sono state inviate all'indirizzo email fornito. Se non ricevi un'email, controlla di aver fornito l'indirizzo corretto.

farebbe il trucco.

Se l'indirizzo email ti è noto, inviare le informazioni per la reimpostazione della password. Se non esiste, non fare nulla. Un utente reale riceverà il collegamento, mentre un utente malintenzionato non può determinare se un'e-mail è stata inviata o meno.

ha un senso totale.grazie.perché non ci ho pensato prima?
@davshowhan449 - Non preoccuparti, questa è una vulnerabilità molto comune nelle applicazioni web e facilmente persa.La cattiva notizia è che tali problemi vengono effettivamente sfruttati in natura e difficili da mitigare con breve preavviso, quando accade.Pertanto, consiglio di risolverlo in tempo, anche se a prima vista è "solo una divulgazione di informazioni".
e se ci sono pagine che vengono dopo?come termini e condizioni, comunicazioni, FYI, annunci, sondaggi, ecc. prima dell'effettivo invio di e-mail?questo potrebbe influire sull'esperienza dell'utente.Un utente legittimo potrebbe dire, ho fatto tutto questo e alla fine non mi hanno detto che la mia email non era valida?
@davshowhan449 Quindi sbarazzarsi anche di quelle pagine aggiuntive.E buon viaggio, perché suona come un'esperienza orribile in primo luogo.Ma forse vale una nuova domanda.
@davshowhan449 Non credo di averlo mai visto in una pagina di reimpostazione della password.Si presume che tu sia già un membro del servizio, non è necessario chiedere all'utente di accettare T&C.Altre cose non vengono visualizzate finché non rispondi al collegamento inviato via email.
@davshowhan449 Sebbene non sia ancora una grande esperienza utente, un modo per correggere quel flusso di lavoro sarebbe spostare le pagine * necessarie * dopo che l'utente ha fatto clic sul collegamento nella propria e-mail.
#3
+20
Michael P
2020-03-19 19:15:52 UTC
view on stackexchange narkive permalink

In aggiunta alle risposte precedenti (sarebbe più adatto come commento ma non è ancora possibile farlo), un altro passo che l'hacker può compiere è misurare il TEMPO della tua risposta al modulo. Potrebbero essere necessari 10 ms per determinare che l'e-mail non esiste, mentre sono necessari 100 ms per generare un collegamento di ripristino e inviare un'e-mail. L'hacker può sapere se la risposta è più lenta che è una scoperta riuscita. Puoi utilizzare un timer di sospensione casuale nei casi in cui l'email non viene trovata in modo che entrambe le risposte impieghino la stessa quantità di tempo.

Benvenuto nel sito, fai il tuo primo +1!Grazie per la tua aggiunta.Tuttavia, esiste una soluzione ancora più semplice al problema.Invia subito la risposta, senza prima controllare l'email.In questo modo il tempo di risposta è indipendente anche dalla validità dell'indirizzo e-mail.
@Demento Concettualmente facile ma può essere tecnicamente difficile: molti backend web di base non rendono facile l'elaborazione asincrona, perché per impostazione predefinita legano la durata del thread di elaborazione alla risposta HTTP.
@Bob sì, è un po 'più difficile, ma anche molto trattabile.Se hai una coda di messaggi, puoi usarla, o passare a un povero uomo / vecchia scuola con un cron che esegue ogni minuto estraendo elementi da un database di invii di ripristino in sospeso.
Questo problema scompare se si invia un messaggio di posta elettronica "Impossibile reimpostare la password: account non trovato".
Brian ti ho votato positivamente, ma nota che (senza controlli) hai dato all'attaccante A la possibilità di inviare spam all'utente S utilizzando il tuo servizio.
Solo una nota a margine qui: non utilizzare un sonno casuale, può essere filtrato statisticamente.Vedi ad es.https://stackoverflow.com/questions/28395665/could-a-random-sleep-prevent-timing-attacks Un ritardo calcolato per essere abbastanza lungo da far sì che entrambe le risposte impieghino lo stesso tempo può essere d'aiuto, ma casuale no.
Se invii la stessa risposta a tutti, come suggerito nelle altre risposte, la risposta HTTP può essere molto semplice, anche una pagina HTML statica o un reindirizzamento.Il controllo e l'invio vengono eseguiti in modo asincrono o se il framework non lo supporta dopo che la risposta è stata inviata.Cioè invece di controllare, inviare, rispondere, è rispondere, controllare, inviare.
#4
+20
David Mulder
2020-03-20 14:10:14 UTC
view on stackexchange narkive permalink

Da cosa stiamo proteggendo?

Prima di tutto ci si dovrebbe chiedere da cosa stanno proteggendo esattamente. In questo caso ci sono due diverse minacce:

  • Minaccia 1 Un bruto aggressore forza le email casuali a trovare email registrate valide. Questo potrebbe essere teoricamente utilizzato per creare elenchi di spam, ma per quanto ne so non è mai stato fatto in quanto è più semplice inviare le e-mail piuttosto che passare attraverso i problemi extra (il numero di volte che ho ricevuto messaggi di spam che rivendicano il mio [alcuni Stati Uniti conto bancario] azione necessaria nonostante non risieda negli Stati Uniti è innumerevole).
  • Minaccia 2 Un utente malintenzionato sta prendendo di mira un utente specifico o un elenco di utenti specifici. Ciò è particolarmente importante quando il semplice fatto che qualcuno sia registrato da qualche parte può avere delle conseguenze. Esempio: l'atto stesso di avere un account su Grindr o Ashley Madison può essere pericoloso in alcune comunità.

Il quadro più ampio

La prossima domanda a cui pensare è quale altri luoghi potrebbero esporre le stesse informazioni e considerarle nel loro insieme. In genere il modulo di registrazione informerà l'utente se l'email inserita è già registrata, ma questo ovviamente non si applica alla maggior parte dei software B2B. Oltre a queste funzionalità di "condivisione con l'utente" (una casella di input in cui è possibile inserire un messaggio di posta elettronica per condividere un oggetto con questo utente) spesso verranno visualizzate anche queste informazioni, ma poiché sono rare non le includerò in questa risposta.

Soluzioni per un sistema con registrazione pubblica

Prima di tutto è bene riconoscere che non informare l'utente che un account esiste già durante il processo di registrazione è da un punto di vista UX molto spiacevole. Lo stesso vale per i moduli di reimpostazione della password che non riescono silenziosamente 1 quando l'utente fa un errore di battitura o ha più email. Ciò non significa che sia qualcosa che non si dovrebbe fare, ma è necessario valutarlo rispetto ai rischi e ai vantaggi per la sicurezza.

Dato un sistema con registrazione pubblica, la cosa importante da considerare è quanto è grande la minaccia 2 per gli utenti del tuo prodotto. Dato anche un rischio modesto può essere prudente cambiare il modulo di registrazione per iniziare inserendo solo un nome e una email, dando un messaggio "controlla la tua email per continuare la registrazione", e se la email è già registrata inviando all'utente una email informativa loro di questo. Allo stesso modo in quel caso il modulo di reimpostazione della password non informerà in alcun modo l'utente se l'email è valida.

D'altra parte, se la Minaccia 2 è minima, dobbiamo modellare esclusivamente contro la Minaccia 1 . Ovviamente l'approccio precedente funzionerà perfettamente anche contro la minaccia 1 esclusivamente, ma considerando il costo della UX vale la pena considerare altre soluzioni. La soluzione più ovvia è la limitazione della velocità 2 per entrambi i controlli "controllo presenza posta elettronica" e "password dimenticata" (tecnicamente queste chiamate possono anche arrivare allo stesso endpoint API). Questi sono spesso progettati per essere abbastanza indulgenti per le prime 10 chiamate circa, ma diventano molto limitati molto rapidamente dopo quel punto.

Importante : non rimuovere mai i messaggi di errore dalla password registrazione senza implementare restrizioni simili sul modulo di registrazione.

Soluzioni per un sistema senza registrazione pubblica

Tutto si riduce agli stessi problemi di cui sopra (e avrei dovuto scrivere questo prima ), ma senza il costo "extra" dell'hit per la registrazione UX è relativamente "più economico" avere un modulo sicuro per la password dimenticata, anche se ovviamente è ancora spiacevole per gli utenti e puoi ancora considerare se la limitazione della velocità non è sufficiente per il tuo modello di minaccia specifico.

Note

1: Invece di fallire silenziosamente, è saggio inviare almeno un'e-mail all'e-mail inserita per informarli che la loro e-mail non è stata trovata. Questo 1) demotiva gli aggressori dall'abuso di massa del sistema (come si noterà) e 2) impedisce agli utenti di chiedersi perché non ricevono un'email.

2: Sì si noti che la limitazione della velocità può influire negativamente sugli utenti di reti di grandi dimensioni o VPN. Considera sempre quanto sia importante quel pubblico per te e, in base a ciò, dedica una quantità di tempo adeguata per garantire che l'applicazione rimanga funzionante anche quando la limitazione della velocità è più severa (ad es. Abbassando il limite di velocità risolvendo un captcha o impostando il limite di velocità massimo a circa una volta al minuto e assicurandoti che l'applicazione attenda l'intero minuto (nota: sarà comunque spiacevole dato che un team di utenti si iscrive allo stesso servizio all'inizio della stessa riunione)).

Non andrebbe bene anche questo: "Ti è stata inviata una e-mail per continuare la registrazione, se sei già registrato non riceverai nessuna e-mail."Ciò impedirebbe a un utente malintenzionato di inviare spam a un indirizzo e-mail noto.
@SAJW Penso che quello che stai descrivendo sia lo stesso che ho descritto quando ho scritto "Dato anche un modesto rischio, può essere prudente cambiare il modulo di registrazione per iniziare solo inserendo un nome ed e-mail, dando un messaggio" controlla la tua e-mail acontinua a registrarti "".Ma se hai idea di come renderlo più chiaro o migliore: sentiti libero di modificare
Ah, non importa.La tua strada è sufficiente perché se un utente malintenzionato conosce la tua e-mail, può inviarti spam se NON sei registrato, quindi non guadagniamo molto con la mia soluzione.
@SAJW In qualche modo ho letto completamente male il tuo commento e ora è chiarissimo ....Ma sì, in generale fallire silenziosamente è super pericoloso, perché l'utente non sa mai se un server di posta lento o un filtro antispam ha catturato la sua e-mail, o se in realtà dovrebbe non riceverla.
#5
+8
Džuris
2020-03-20 07:05:59 UTC
view on stackexchange narkive permalink

Dovresti valutare il problema rispetto all'inconveniente della soluzione. È spesso un compromesso.

Secondo me di solito è meglio sacrificare questo po 'di sicurezza per il bene dell'esperienza dell'utente a meno che qualcuno non venga perseguitato per essersi registrato nel tuo sito.

Di tanto in tanto, anni dopo, vengo su un sito e cerco di trovare quale e-mail ho usato per quel determinato sito. I siti che nascondono queste informazioni sono piuttosto fastidiosi.

Una grande aggiunta alle altre risposte.Ogni funzionalità di sicurezza dovrebbe essere valutata per il contesto corrente per decidere se vale la pena fare i costi.La risposta non è sempre "sì".
Nel caso in cui non so quale e-mail ho usato, cercherò spesso il nome del sito attraverso i miei indirizzi e-mail principali per vedere con quale mi sono registrato.Particolarmente utile incongruenza con la funzione google di poter aggiungere + qualsiasi cosa al tuo indirizzo email.
Non si tratta solo di persecuzione, ma anche di phishing.Immagina che qualcuno riceva un messaggio di "reimpostazione della password" e 5 minuti dopo abbia ricevuto un messaggio apparentemente dal tuo sito web che diceva "Abbiamo riconosciuto un accesso / acquisto dal tuo account che potrebbe non provenire da te. Vai su www.thisisascam.com per controllarese il tuo account è stato compromesso ".Molte persone accederanno al sito Web della truffa, perché l'e-mail di ripristino le ha innescate e il truffatore sa che la persona ha un account con te, quindi può formattare il messaggio in modo diverso rispetto a un messaggio di spam generico.
@Morfildur: La maggior parte dei phisher non si preoccupa di verificare l'esistenza dell'account prima di inviare le proprie e-mail.Ecco perché ricevi e-mail di phishing per servizi che non utilizzi.
#6
+1
eckes
2020-03-21 09:42:52 UTC
view on stackexchange narkive permalink

Nota che questo (oltre alle altre risposte) vale anche per la schermata di registrazione, invece di lamentarti che l'utente già registrato ha inviato loro un'e-mail che è già registrato e non fornisce alcun feedback sull'app web oltre a "controlla la tua posta ".

È meglio farlo se chiedi un input minimo sul primo passaggio prima della convalida dell'email (il che è positivo anche per il GDPR, dove puoi dimostrare che l'utente ha ricevuto la tua email informativa e ha continuato a registrarsi ).

In effetti non è un problema per la registrazione e dovrebbe essere sempre fatto. Per la funzione di reimpostazione della password forniamo un'opzione nel software in cui è possibile selezionare il feedback diretto o il feedback tramite e-mail. (Negli scenari aziendali, in particolare sulla Intranet, indovinare le e-mail non è una vera minaccia).



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...