Perché i collegamenti "Password dimenticata?" in genere rivelano nomi utente o indirizzi e-mail registrati? [duplicare]

Sì, sono davvero delle cattive pratiche di sicurezza.

Quando si utilizza la funzione Password dimenticata, il sito dovrebbe rispondere con un messaggio: "Una e-mail è appena stata inviata all'indirizzo e-mail specificato, se esiste ed è registrato nel nostro sistema. Leggere l'e-mail e seguire le istruzioni. "

O semplicemente: "Controlla la tua casella di posta elettronica per le istruzioni su come procedere per reimpostare la password" , poiché è un presupposto sicuro che la procedura di reimpostazione dell'account sia stata avviata dal legittimo proprietario dell'account.

EDIT: È stato sottolineato che un utente malintenzionato potrebbe scoprire se un indirizzo email è registrato nel sistema tentando di aprire un account con quell'indirizzo. Per contrastare questo attacco, anche la procedura di registrazione deve essere modificata; l'utente dovrebbe essere autorizzato a registrarsi solo dopo aver verificato il suo indirizzo email, come segue.

Dopo aver inserito un indirizzo email per una nuova registrazione, il sito dovrebbe rispondere con il messaggio "È stata inviata un'email all'indirizzo di posta elettronica fornito. Leggere l'e-mail e seguire le istruzioni per completare la registrazione, se necessario ". Quindi il messaggio di posta elettronica conterrà le istruzioni da seguire per completare la registrazione o un semplice avviso all'utente se l'indirizzo di posta elettronica è già stato registrato.

C'è una ragione per cui pochi siti web seguono questa misura di "sicurezza": perdi l'usabilità (e gli utenti) senza ottenere qualsiasi sicurezza.

Qualsiasi sito web con il minimo accenno di sicurezza imporrà un limite al numero di volte in cui è possibile "indovinare" una password O un nome utente, per impedire agli utenti di iterare su tutti i nomi utente esistenti. Questo limite deve essere imposto su tutti gli aspetti; registrazione, login e recupero password.

Potresti chiederti: "Se è così brutto dare un messaggio di errore generico, perché la gente lo fa?". La risposta arriva dal lontano passato, quando la sicurezza era giovane e sottosviluppata. L'autenticazione veniva spesso eseguita offline o su una rete locale, il che consentiva agli aggressori di applicare la forza bruta alla velocità consentita dal loro processore. Con un numero illimitato di tentativi avvenuti a un ritmo rapido, è stato banale scorrere su ogni nome utente esistente, se il sistema ha segnalato che un nome utente esisteva o meno.

Le aziende più grandi (Facebook, ad esempio) tendono ad avere divisioni UI / UX che eseguono test di usabilità, mostrando solo quanti utenti sono persi a causa di un teatro di sicurezza anti-usabilità. Ma molte aziende più piccole non hanno risorse UI / UX e finiscono per seguire "best practice" come questa, e anche cose più stupide come " immagini di sicurezza ".

Lettura correlata: Divulgare all'utente se l'account esiste?

Qui ci sono una serie di problemi che devono essere considerati e alcuni troppo spesso ha citato la falsa dichiarazione di sicurezza attraverso l'oscurità.

Per affrontare la sicurezza attraverso dichiarazioni di oscurità. Fare qualcosa di oscuro fa non implicano automaticamente la sicurezza attraverso l'oscurità. La nozione di sicurezza attraverso l'oscurità si riferisce alla pratica di affidarsi esclusivamente all'oscurità per il sicurezza. È perfettamente accettabile e in alcuni casi anche una buona pratica incorporare l'oscurità in un controllo di sicurezza.

Come esempio delle differenze. Considera telnet, che è intrinsecamente insicuro perché invia le password in testo semplice. Spostare il servizio telnet dal suo standard porta ad un'altra porta e credendo che questo abbia affrontato il problema di sicurezza sicurezza attraverso l'oscurità. Non ha affrontato il problema di fondo del testo normale le password vengono trasmesse e non fa affidamento su nessuno che annusa il traffico destinato a questo porta non standard per mantenere la sicurezza.

D'altra parte, potresti decidere di spostare il tuo servizio SSH su un non standard porta. Questa decisione potrebbe essere perché si dispone di un sistema in cui si accede solo e hai notato molti tentativi di accesso alla forza bruta tramite ssh. Spostando questo servizio a un'altra porta non standard ridurrà il numero di tentativi di forza bruta contro il tuo servizio ssh. Dato che sei l'unico ad usarlo, non rappresenta un significato inconveniente e mentre ha reso quel servizio più oscuro, non è classificato come sicurezza attraverso l'oscurità perché spostarlo su un altro porto non è l'unica sicurezza protezione. Hai ridotto l'esposizione alle minacce, ma stai ancora utilizzando tutto il altre buone pratiche standard che avresti per un servizio SSH.

L'oscurità nella sicurezza è un controllo comune e perfettamente accettabile a condizione che non lo sia l'unico controllo su cui ti basi.

Rispetto alla domanda originale per indicare se l'e-mail o il nome utente sono valido quando si esegue un'operazione di recupero della password è una buona idea, dipende davvero su molti altri fattori. I controlli di sicurezza devono essere valutati nel contesto sono stati applicati a. Abbiamo linee guida generali sulle "migliori pratiche", ma queste sono solo quello, linee guida, non regole. In generale, non vogliamo fornire informazioni agli attaccanti che possono usare per assisterli nel loro attacco. Tuttavia, abbiamo anche bisogno considerare il valore della risorsa che stiamo proteggendo.

Ad esempio, utilizzo un servizio di lettura di feed RSS. Per me, questo è un basso rischio applicazione. Non c'è molto valore per un attaccante. Se dimentico il mio password e prova a usare la funzione password dimenticata e mi dice che non è riuscita piuttosto che dirmi che avevo l'indirizzo email sbagliato, allora probabilmente sarà di più frustrante del necessario. Potrebbe essere che ho avuto un refuso nell'indirizzo che ho inserito e sentirsi dire che l'indirizzo era sbagliato avrebbe davvero aiutato. So che il problema è con quello che ho inserito Dicendomi qualcosa di troppo generico mi impedisce di provarci diagnosticare cosa c'era di sbagliato - era qualcosa di sbagliato che ho inserito, è un problema con il loro server, che cosa?

D'altra parte, probabilmente non voglio che la mia banca usi una funzione di password dimenticata che fornirà informazioni aggiuntive, come il nome del mio account a un utente malintenzionato. Nel questo caso, forse un messaggio che indica che la funzionalità della password dimenticata ha fallito e chiedendomi di contattare l'assistenza telefonica sarebbe più appropriato. Se sul D'altra parte, il problema è con il mio account Gmail, probabilmente non sono interessato perché è banale determinare indirizzi e-mail validi e non validi usando semplicemente di base Comandi SMTP al server.

Il punto fondamentale è che è necessario bilanciare l'esperienza dell'utente e la sicurezza. Devi capire quali sono i vettori delle minacce e quali sono i controlli appropriati per il risorsa protetta. Non c'è sempre dovrebbe essere questo o quello - tutto viene giù al contesto.

Sì, è una cattiva pratica, esattamente per le ragioni che hai indicato.

Quando scrivo questo tipo di cose, faccio un messaggio generico sulla falsariga di "Un'email è stata inviata a questo indirizzo" indipendentemente dal fatto che l'account esistesse o meno.

C'è un fattore attenuante, tuttavia, in quanto un hacker che cerca di utilizzare un modulo come questo individua gli indirizzi registrati che attiveranno le e-mail da inviare agli utenti di cui trova gli indirizzi. Questo potrebbe servire da avvertimento per l'utente. In effetti, alcuni siti includono messaggi di avvertimento nelle loro e-mail per gli utenti che si guardano da un potenziale attacco se non hanno richiesto il ripristino.

Questo potrebbe essere sufficiente per dissuadere gli hacker dal tentare di utilizzare il modulo di ripristino per raccogliere gli indirizzi.

Come ha detto @Ahueahuehauehua, la risposta @ dr01 non è amichevole per l'utente, secondo me.

Always remember that security through obscurity IS NOT a valid approach.

Invalid username or password dice semplicemente che username e password non corrispondono, voglio dire, sia il nome utente che la password (o entrambi) non sono corretti. Quindi, in ogni caso, mostra solo un messaggio come Invalid username or password , non a causa della sicurezza (che non è affatto sicura), ma perché il nome utente o la password o entrambi sono errati.

Il modo migliore è quello di aumentare la sicurezza di accesso, dalle migliori pratiche e non dall'oscurità. Prova a limitare i tentativi di accesso / registrazione / password dimenticata. Ad esempio, limitarli a 5 tentativi / IP / ora e anche 5 tentativi / nome utente / ore. Inoltre, impostare un numero massimo di tentativi per 24 ore (ad esempio, 10 tentativi / IP / 24 ore e 10 tentativi / nome utente / 24 ore). Quindi, nessuno può indovinare più di 3650 password in un anno per ogni nome utente.

Voglio solo dirlo di nuovo che security through obscurity is not a valid approach.