No, hai ragione sul fatto che a un certo punto durante gli sforzi per impedire agli aggressori di determinare identità utente valide, dovrai mentire loro o fornire messaggi di errore eccezionalmente vaghi.

La tua app potrebbe indicare a un utente che "il nome utente richiesto non è disponibile" e non specificare se era già in uso o semplicemente non soddisfaceva gli altri requisiti del tuo nome utente (lunghezza, utilizzo dei caratteri, riservato parole, ecc.). Naturalmente, se questi dettagli sono pubblici, un utente malintenzionato potrebbe scoprire che la sua ipotesi non è riuscita a causa dell'account in uso e non a causa di un formato non valido.

Quindi hai anche il tuo sistema di reimpostazione della password. Accetti un nome utente / indirizzo e-mail e dici che un messaggio è stato inviato anche se quell'account non era nel tuo database? E il blocco dell'account (se lo stai usando)? Dici semplicemente all'utente che le sue credenziali non erano valide anche se non lo erano, ma invece il suo account è stato bloccato, sperando che contatti l'assistenza clienti che può identificare il problema?

È utile aumentare il difficoltà per gli aggressori nel raccogliere nomi utente validi, ma in genere ciò comporta la frustrazione degli utenti. La maggior parte dei siti a bassa sicurezza che ho visto utilizza messaggi separati che identificano se il nome utente o la password sono sbagliati solo perché preferiscono sbagliare per mantenere gli utenti felici. Dovrai determinare se i tuoi requisiti di sicurezza impongono la priorità rispetto all'esperienza utente.

Stai partendo dal presupposto che il sistema sappia effettivamente quale campo è stato inserito in modo errato. Ci sono diversi motivi per cui questo non è necessariamente vero.

Una possibilità è che sia un effetto collaterale dell'implementazione. Un metodo semplicistico per cercare gli accessi in un database potrebbe essere simile (utilizzando : n per i parametri forniti dall'utente):

  SELECT 1 FROM users WHERE username = : 1 AND password = HASHING_FUNCTION (CONCAT (: 2, salt))  

Se ottieni un risultato vuoto, sai che il login dovrebbe fallire, ma non sai perché se non lo fai qualcosa di più complicato o fai un'altra query. Quindi a volte può essere solo pigrizia o il desiderio di andare piano con il database, piuttosto che una decisione di sicurezza consapevole.

Ma anche se l'implementazione può distinguere tra un utente inesistente e credenziali errate, hai ancora il situazione in cui un utente immette la password correttamente, ma il nome utente sbagliato, e si tratta di un utente esistente (con una password diversa). Quindi, se l'utente riceve un messaggio che dice che la sua password non è corretta, sarebbe sbagliato. Quindi, a meno che il nome utente specificato non esista, il sistema non può sapere se era il nome utente o la password sbagliati.

In generale, è più difficile forzare una pagina di registrazione che forzare una pagina di accesso, quindi beneficiamo di questo costo aggiuntivo. Ma, in teoria, hai ragione. Esistono altri modi per enumerare i nomi utente oltre ai messaggi delle pagine di accesso.

È semplicemente "buona pratica" (TM) mantenere generici i messaggi di errore di accesso in modo da rendere più difficile per gli aggressori raccogliere account buoni da account cattivi. Utilizzando uno strumento di forza bruta, è banale provare nomi casuali e quindi, quando il messaggio di errore cambia, avviare la forzatura bruta di quel nome utente.

Ma, come sempre, è necessario bilanciare l'usabilità con la riduzione delle minacce.

Non tutti i sistemi hanno la registrazione dell'account. Ad esempio, il login del tuo sistema operativo non lo fa. I siti web di tanto in tanto smettono di accettare nuovi membri.

È una questione di separazione delle preoccupazioni: la finestra di dialogo di accesso dovrebbe interrogare la configurazione del sistema e personalizzare il suo comportamento in base al fatto che il sistema sia configurato per accettare le applicazioni per nuovi conti o no? Quindi la finestra di dialogo di accesso è accoppiata a informazioni che non sono realmente rilevanti per il suo lavoro.

Sembra più semplice implementare solo il vago messaggio di errore in tutti i casi (supponendo che il software dell'interfaccia utente sappia anche se si tratta della password questo non va bene o l'account è inesistente: cosa succede se riceve un errore di autenticazione generico da un'API di livello inferiore?)

E inoltre: la nuova interfaccia utente dell'applicazione utente può implementare un ritardo falso di lunga durata come " ricerca nella base utenti ... [10 secondi] ... oops, il nome utente è già stato preso! " Se viene implementato, significa che sondare lo spazio degli ID utente attraverso questo meccanismo è fortemente limitato. Poiché la richiesta di un nuovo account è un'operazione rara e una tantum, gli utenti subiranno il ritardo, mentre cresceranno aggravati da un ritardo di dieci secondi nella normale finestra di dialogo di accesso.

Dipende da quale sia il nome utente. Esistono tre approcci principali per i nomi utente:

• Nome selezionato dall'utente
• Indirizzo e-mail
• Nome utente assegnato, di solito una stringa di cifre

Hai ragione sul fatto che per i nomi selezionati dall'utente, un utente malintenzionato può utilizzare il processo di registrazione per dedurre quali nomi sono in uso, quindi c'è un vantaggio limitato all'accesso che restituisce un messaggio generico.

Tuttavia, per gli altri due casi, è molto più importante che la schermata di accesso restituisca un messaggio di errore generico. Considera un sito di reclutamento, potrebbe essere imbarazzante per joe.bloggs@abc.com far scoprire al suo capo che esiste un account su un sito di reclutamento. E i nomi utente assegnati sono più comunemente usati su siti ad alta sicurezza come l'online banking.

Sì, hai ragione. Ovunque nel tuo sito sia possibile confermare l'esistenza o meno di un nome utente può portare a enumerazione del nome utente.

Tuttavia, questo problema può essere risolto se è importante per il tuo sistema. In alcuni sistemi, l'enumerazione del nome utente non può essere evitata poiché è inerente alla natura dell'applicazione. Un esempio è un servizio di posta Web: qui gli indirizzi e-mail sono considerati potenzialmente pubblici. Impedire agli utenti di conoscere altri nomi utente è difficile senza richiedere agli utenti di accedere con un identificatore diverso dal loro indirizzo email ospitato e può creare confusione e difficoltà nel recuperare le credenziali perse.

Tuttavia, con la maggior parte degli altri sistemi questo può essere corretto impostando l'indirizzo email dell'utente come nome utente di accesso. Risolveresti il ​​problema avendo la password dimenticata e il modulo di iscrizione in modo altrettanto efficace nella stessa pagina. Per l'iscrizione, questo sarebbe un modulo a più passaggi e il primo passaggio richiede semplicemente il nome utente (e-mail) che l'utente desidera utilizzare con il proprio sistema. Per il recupero dell'account, questa sarebbe la stessa forma, ma il titolo direbbe qualcosa sulla falsariga di Inserisci il tuo indirizzo email per generare un'e-mail di recupero password .

In entrambi i casi, il modulo invierà all'utente un'e-mail. Se sono già registrati, il contenuto di questa e-mail contiene un collegamento per la reimpostazione della password. Se non sono registrati, il contenuto di questa e-mail contiene un collegamento alla fase successiva del processo di registrazione. Ciò impedirà che i nomi utente sul tuo sistema vengano enumerati in modo che un utente malintenzionato non saprà quali account prendere di mira.

Ovviamente questo implica che sei disposto a consentire la reimpostazione delle password tramite e-mail che potrebbe essere inaccettabile per alcune applicazioni come le applicazioni bancarie. Tuttavia, poiché questi tipi di account di solito hanno controlli di sicurezza aggiuntivi, di solito hanno nomi utente assegnati dalla banca piuttosto che consentire alle persone di sceglierne uno proprio.

L'argomento comune per messaggi vaghi sembra essere quello di impedire agli aggressori di indovinare nomi utente validi. In realtà esiste una soluzione semplice che non ha un impatto grave sugli utenti legittimi e dovrebbe comunque essere in atto: limitare il numero massimo di tentativi non riusciti in un periodo di tempo.

Limitando i tentativi, si impedisce a tutti forza gli attacchi. Supponiamo che consenti solo 5 tentativi ogni 15 minuti (comune nei forum), che rende un attacco che indovina il nome utente quasi inutile. Previene anche il brute-force delle password (inutilmente lento come sarebbe su un sito remoto comunque).

Ovviamente, un attaccante potrebbe già avere un database di nomi utente e desidera semplicemente controllare se esistono sul tuo sito. E dovrai considerare le implicazioni sulla sicurezza di ciò, ma generalmente o hanno già la password (rendendo questa discussione discutibile) o non lo faranno (quindi i tentativi limitati impediscono comunque di indovinare).

Un sito web intelligente avrebbe un captcha nella pagina di registrazione per impedire questo genere di cose.

Ma sai come è il 99% dei siti web. Rovineranno la loro UX con un messaggio di errore generico, anche se non fornisce loro alcuna sicurezza aggiuntiva. Personalmente, non mi preoccupo dei messaggi di errore generici poiché ci sono molte altre restrizioni in atto per i miei accessi (captcha, tentativi di accesso limitati), inoltre gli accessi sono come il motivo numero 1 per cui le persone abbandoneranno un sito web.

Se scegli di visualizzare un messaggio di errore generico, allora buon dio, seguilo fino in fondo. Assicurati che non ci siano questioni in sospeso da nessuna parte. Puoi rinforzare un muro con acciaio spesso 10 pollici, ma ciò non aiuterà se c'è una porta sbloccata.

Sto cercando di indossare il cappello da hacker e vedo 2 casi:

1. Il tuo sito ha una pagina di registrazione (come gmail o stackoverflow). Potrei usare la pagina di registrazione per capire il nome utente di un utente esistente con la forza bruta. Oppure potrei semplicemente creare un nuovo utente. Il mio nuovo utente gmail o stackoverflow avrà probabilmente più o meno gli stessi diritti di quello che avrei forzato.

2. Il tuo sito non ha una pagina di registrazione. Il tuo punto è nullo.

Per evitare l'enumerazione del nome utente nella pagina di registrazione dell'utente, un'applicazione può allocare automaticamente il nome utente in base all'indirizzo e-mail dell'utente piuttosto che chiedere all'utente di sceglierne uno tra quelli scelti.

In questo modo è possibile impedire il nome utente enumerazione o pagina di registrazione.

Inoltre, dovremmo prendere in considerazione la funzionalità della password dimenticata, a volte dovrebbe rivelare anche dettagli utente validi.