Enumerazione dei nomi utente?

Lascia che ti mostri un esempio di uno scenario ipotetico ma molto plausibile.

C'è un aspirante hacker di nome Bob. Una bella mattina di sole, Bob ha trovato un difetto di iniezione SQL in un noto sito di social networking chiamato HandBook. Usando detto difetto di SQL injection, Bob è riuscito a scaricare un elenco di indirizzi e-mail e password di account registrati con HandBook. Dato che HandBook ha un team di sicurezza schifoso, tutte le password sono sottoposte a hash con hash con MD5 . Cracking apre il suo fidato tavolo arcobaleno, Bob riesce a recuperare le password in chiaro dell'86% degli account utente.

Che cosa farà dopo Bob? Bob sa che l'86% delle persone su HandBook sono adolescenti. Che cosa amano gli adolescenti più del one sito di social networking? Due siti di social networking, naturalmente! Bob decide di provare tutte le combinazioni di indirizzi e-mail e password che è riuscito a contrastare con il servizio di autenticazione di un secondo popolare sito di social networking, Chatter. Dato che gli adolescenti sono adolescenti, non hanno politiche di password forti. Bob riesce ad accedere al 76% degli account utente semplicemente provando la stessa password o una variante simile. È stato in grado di farlo molto rapidamente poiché il modulo di accesso di Chatter lo ha gentilmente informato quando stava tentando di accedere con un indirizzo email inesistente.

È un difetto? Sì, potenzialmente. Ne ho parlato in un'altra delle mie risposte . È stato sottolineato che questo potrebbe non essere un problema importante se i nomi utente degli account registrati possono essere enumerati in un altro modo, ad esempio attraverso la pagina di registrazione. Tuttavia, molte pagine di registrazione sono protette con CAPTCHA, il che rende i tentativi automatici contro di essa molto più difficili.

Questa è una tradizione antica.

Nei vecchi tempi , le persone utilizzavano mainframe e password molto povere, quindi proteggi l'account i nomi erano "importanti": se un utente malintenzionato conosceva il nome di un utente reale, poteva provare a utilizzare le password e, in quel momento, provare a utilizzare alcune dozzine di password.

Naturalmente, questo non è stato soddisfacente, perché i nomi dell'utente non sono realmente informazioni segrete. Era molto meglio avere password sicure.

Al giorno d'oggi , nascondere i nomi degli utenti è meno importante e anche impossibile in alcuni contesti. Ad esempio, quando un utente si registra su un sito Web, utilizzando un "nome" di sua scelta, il sito Web DEVE avvisarlo dei duplicati e ciò è inevitabile; il sito non può tollerare due utenti con lo stesso nome. In questo contesto, non è possibile nascondere in modo reale i nomi degli utenti; quindi, nascondere i nomi degli utenti è meglio che sia inutile. Come menziona @Terry, CAPTCHA nelle pagine di registrazione può rendere più difficile l'enumerazione dei nomi utente in automatico (ma "più difficile" non è lo stesso di "difficile").

Quindi i messaggi di accesso non riusciti che non distinguono tra un nome di accesso inesistente e una password errata, sono ancora ampiamente utilizzati, ma più per motivi di tradizione che per motivi strongmente razionali .

Si noti, tuttavia, che esistono botnet che tentano di replicare provando gli accessi SSH su indirizzi IP casuali, con "nomi utente e password comuni". Basta esaminare il file auth.log di un server Linux, vedrai questi tentativi. Queste botnet lo hanno fatto per anni. Loro potrebbero fare questo per senso della Tradizione (non c'è ragione di credere che le persone malvagie siano più competenti in ciò che fanno delle persone non cattive), ma è possibile che questo tipo di brutale la forza funziona davvero con una probabilità di successo non trascurabile; e un messaggio di errore che distingue tra un brutto nome di accesso e una cattiva password può solo aiutare questi botnet.

Pertanto, mentre l'intera nozione di evitare di fugare i nomi degli utenti è in gran parte un residuo storico dei vecchi tempi, può ancora avere un certo valore in alcuni casi angusti, principalmente forza bruta di massa da parte di un insensato attaccante.

Se un attaccante sta facendo un attacco di ingegneria sociale. L'autore dell'attacco potrebbe inserire un indirizzo email della vittima all'interno del modulo di accesso. Quindi saremo in grado di sapere se la vittima è registrata o meno sotto una specifica email. Se la vittima è registrata su un sito Web, l'utente malintenzionato creerebbe un account su quel sito Web e tenterebbe un attacco di social engineering. Non penso che fermerà l'attaccante ma non dando il messaggio "L'email che hai inserito non esiste", dovrebbe rallentare l'attacco.

È possibile aggiungere un elenco massiccio di nomi utente pubblici al database e non consentire agli utenti di sceglierli e rispondere con un errore generale. In questo modo, un utente malintenzionato non può distinguere tra un utente valido e non valido.

Lo svantaggio sarebbe: 1- limitare gli utenti a scegliere il loro nome utente deliberato 2- Diminuire le prestazioni aggiungendo una nuova query nei nomi utente falsi

qualche idea?