Messaggio di errore generico per password o nome utente errati - è davvero utile?

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

La tua app potrebbe dire a un utente che "il nome utente richiesto non è disponibile" e non essere specifico se era già in uso o semplicemente non ha soddisfatto gli altri requisiti di nome utente (lunghezza, utilizzo dei caratteri, parole riservate, ecc. ). Ovviamente, 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.

Allora hai anche il tuo sistema di reset della password. Accettate qualsiasi nome utente / indirizzo email e dite che è stato inviato un messaggio anche se quell'account non era nel vostro database? Che dire del blocco degli account (se lo stai usando)? Devi solo dire all'utente che le loro credenziali non erano valide anche se non lo fossero, ma invece il loro account era bloccato, sperando che contattassero l'assistenza clienti che può identificare il problema?

È utile aumentare la difficoltà per gli aggressori di raccogliere nomi utente validi, ma in genere è un costo di utenti frustranti. La maggior parte dei siti di sicurezza più bassi che ho visto utilizzano messaggi separati che identificano se il nome utente o la password sono sbagliati solo perché preferiscono commettere errori nel mantenere gli utenti soddisfatti. Dovrai determinare se i tuoi requisiti di sicurezza impongono la priorità sull'esperienza utente.

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

Una possibilità è che si tratta di un effetto collaterale dell'attuazione. Un metodo semplicistico per cercare gli accessi in un database potrebbe sembrare qualcosa di simile (usando :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é a meno che tu non faccia qualcosa di più complicato o faccia un'altra query. Quindi, a volte può essere solo la pigrizia o il desiderio di semplificare il database, piuttosto che una consapevole decisione di sicurezza.

Ma anche se l'implementazione è in grado di distinguere tra un utente inesistente e credenziali errate, si ha comunque la situazione in cui un utente inserisce correttamente la propria password, ma il nome utente errato e quello che si verifica è un utente esistente (con una password diversa ). Quindi, se l'utente ha ricevuto un messaggio che diceva che la sua password era errata, sarebbe sbagliato. Quindi, a meno che il nome utente specificato non esista, il sistema non può in realtà sapere se era il nome utente o la password errati.

In generale, è più difficile forzare una pagina di registrazione rispetto alla forza bruta di una pagina di accesso, quindi beneficiamo di questo costo aggiuntivo. Ma, nel concetto, hai ragione. Esistono altri modi per enumerare i nomi utente rispetto ai messaggi della pagina di accesso.

È semplicemente "Good Practice" (TM) mantenere generici i messaggi di errore di accesso al fine di rendere più difficile per gli attaccanti raccogliere buoni account da quelli sbagliati. Usando uno strumento di forza bruta, è banale provare i nomi casuali, e poi quando il messaggio di errore cambia, per avviare la bruta forzando 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 tuo login al sistema operativo no. I siti web smettono di accettare nuovi membri di volta in volta.

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

Sembra più facile implementare il vago messaggio di errore in tutti i casi (presupponendo che il software di interfaccia utente sappia anche se la password è sbagliata o l'account inesistente: cosa succede se ottiene un errore di autenticazione generico da un livello inferiore API?)

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

Dipende da cosa è il nome utente. Esistono tre approcci principali per i nomi utente:

• Nome selezionato dall'utente
• indirizzo email
• Nome utente assegnato, solitamente una stringa di cifre

Hai ragione 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 per il login che restituisce un messaggio generico.

Tuttavia, per gli altri due casi, è molto più importante che la schermata di login restituisca un messaggio di errore generico. Considerare un sito di reclutamento, potrebbe essere imbarazzante per [email protected] avere il suo capo scoprire che c'è 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 sul tuo sito, dove è possibile confermare che un nome utente esiste o meno, può portare a enumerazione del nome utente .

Tuttavia, questo problema può essere risolto se è importante per il tuo sistema. All'interno di alcuni sistemi, l'enumerazione dei nomi utente non può essere evitata in quanto inerente alla natura dell'applicazione. Un esempio è un servizio di posta Web: qui gli indirizzi di posta elettronica sono considerati potenzialmente pubblici. Impedire agli utenti di conoscere altri nomi utente è difficile senza richiedere agli utenti di accedere con un identificatore diverso rispetto al loro indirizzo email ospitato e può portare a confusione e difficoltà nel recupero delle credenziali perse.

Tuttavia, con la maggior parte degli altri sistemi questo può essere risolto avendo l'indirizzo e-mail dell'utente come nome utente di accesso. Risolvi il problema avendo la password dimenticata e il modulo di registrazione come effettivamente la stessa pagina. Per iscriversi, questo sarebbe un modulo multi-step e il primo passo 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 Please enter your email address to generate a password recovery email .

In entrambi i casi, il modulo invierà all'utente un'e-mail. Se sono già registrati, il contenuto di questa email contiene un link per la reimpostazione della password. Se non sono registrati, il contenuto di questa email contiene un collegamento alla fase successiva della procedura di registrazione. Ciò impedirà l'enumerazione dei nomi utente sul tuo sistema in modo che un utente malintenzionato non sappia quali account scegliere come target.

Ovviamente ciò implica che si è disposti a consentire la reimpostazione delle password via e-mail, il che potrebbe non essere accettabile 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 bancari piuttosto che consentire alle persone di sceglierne uno.

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 essere comunque presente: limitare il numero massimo di tentativi falliti in un periodo di tempo.

Limitando i tentativi, si prevengono tutti gli attacchi di forza bruta. Supponiamo che tu permetta solo 5 tentativi per 15 minuti (comune sui forum) - questo rende un attacco di indovinare il nome utente quasi inutile. Impedisce anche la forzatura brute delle password (come inutilmente lento come sarebbe comunque su un sito remoto).

Naturalmente, un utente malintenzionato potrebbe già disporre di un database di nomi utente e desidera semplicemente verificare se esistono sul tuo sito. E dovrai considerare le implicazioni sulla sicurezza di questo, ma generalmente hanno già la password (rendendo questa discussione discutibile) o non lo faranno (quindi i tentativi ristretti impediscono comunque di indovinare).

Un sito Web intelligente dovrebbe avere un captcha nella pagina di registrazione per evitare questo genere di cose.

Ma sai come è il 99% dei siti web. Essi rovineranno il loro UX con un messaggio di errore generico, anche se non fornisce loro ulteriore sicurezza. Personalmente, non mi preoccupo dei messaggi di errore generici poiché ci sono molte altre restrizioni in atto per i miei login (captchas, 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, vai fino in fondo con esso. Assicurati che non ci siano estremità sciolte ovunque. Puoi rinforzare un muro con acciaio spesso 10 pollici, ma questo non ti aiuterà se c'è una porta sbloccata.

Sto cercando di mettere il mio cappello attaccante 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 tramite la forza bruta. O potrei semplicemente creare un nuovo utente. Il mio nuovo utente Gmail o StackOverflow probabilmente avrà gli stessi diritti di quello che avrei forzato bruto.

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