Domanda:
Messaggio di errore generico per password o nome utente errati: è davvero utile?
Mirco
2014-07-08 00:41:41 UTC
view on stackexchange narkive permalink

È molto comune (e direi che è una sorta di sicurezza di base) non mostrare nella pagina di accesso se il nome utente o la password erano sbagliati quando un utente tenta di accedere. Si dovrebbe invece mostrare un messaggio generico , come "La password o il nome utente sono sbagliati".

Il motivo non è mostrare ai potenziali aggressori quali nomi utente sono già stati utilizzati, quindi sarà più difficile "hackerare" un account esistente.

Mi sembrava ragionevole, ma poi mi è venuto in mente qualcosa di diverso.

Quando registri il tuo account, digiti il ​​tuo nome utente. E quando è già scattato, viene visualizzato un messaggio di errore, che non è generico!

Quindi, fondamentalmente, un utente malintenzionato potrebbe semplicemente prendere i nomi utente "corretti" dalla pagina di registro, o mi sbaglio?

Allora qual è il punto dei messaggi generici rispetto a? I messaggi non generici porterebbero a una UX molto migliore.

Ci sono siti come Yahoo mail, ad esempio, dove inserire il nome utente corretto e una password errata fornisce il messaggio generico. Inserendo "Nome utente errato" viene visualizzato un messaggio "Questo nome utente non è stato utilizzato ..." tanto per motivi di sicurezza. Penso che questa sia una reliquia dei vecchi tempi e non abbia posto nello schema delle cose di oggi.
Inoltre, quando digiti erroneamente la password nella schermata di blocco di Win7 (dove il nome utente è preselezionato per impostazione predefinita), ottieni comunque il messaggio generico ...
Preferisco la funzione "Password dimenticata", che mi dice anche se il nome utente è valido o meno in molti casi. Il collegamento è solitamente vicino al campo della password, non è necessario andare alla deviazione "Registrati".
Dieci risposte:
#1
+61
PwdRsch
2014-07-08 00:54:19 UTC
view on stackexchange narkive permalink

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.

Se il sito ti consente di * scegliere * un nome utente (senza lo stesso consiglio in atto quando scegli le password), allora è una specie di scherzo mantenere segreti i nomi utente. OK, alcuni utenti trarranno vantaggio dalla segretezza poiché sceglieranno nomi utente difficili da indovinare, ma l'utente "dave" non otterrà questo vantaggio indipendentemente dalle misure che prendi per cercare di mantenerlo segreto ;-) Quindi è così difficilmente può essere essenziale.
+1 per "... determina se i tuoi requisiti di sicurezza impongono di dare loro la priorità rispetto all'esperienza utente"
Bene, * potresti * combinare la reimpostazione della password e la creazione di un account: qualsiasi account che potrebbe essere creato, in qualche modo esiste, è solo che nessuno conosce la password.
#2
+34
nobody
2014-07-08 02:23:57 UTC
view on stackexchange narkive permalink

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.

Nessun sistema attento alla sicurezza dovrebbe utilizzare questo tipo di autenticazione perché oltre all'hashing, è necessario disporre di un salt. E idealmente, un sale per fila. Quindi cerca per nome, prendi sale e hash, confronta.
E dubito che una corretta HASHING_FUNCTION sia implementata dalla maggior parte dei DBMS, e sospetto anche che questo potrebbe essere suscettibile di attacchi temporali. Non lo farei.
Soprattutto il secondo punto è eccellente! Se l'utente ha un errore di battitura nel suo nome utente, ma corrisponde in modo casuale a un altro nome utente, il messaggio corretto sarebbe "Nome utente errato" perché per l'utente è un nome utente sbagliato, anche se il sistema lo ha trovato nel DB, quindi quello generico è sempre meglio! @Mormegil Penso che il codice sia valido, HASHING-FUNCTION dovrebbe ovviamente essere una funzione di hashing crittograficamente sicura. Ma la tempistica non è un problema, tranne per il fatto che un nome utente probabilmente non è nel DB a causa della scansione veloce dell'indice. Ma come accennato questo è probabilmente irrilevante per la maggior parte delle applicazioni moderne
@Falco Bene, _either_ HASHING-FUNCTION è qualcosa come SHA-256 (che potrebbe essere implementato nel DBMS), che è un hash veloce, _non adatto_ per l'hashing della password, _o_ è qualcosa come PBKDF o BCRYPT (che probabilmente non è fornito da qualsiasi DBMS corrente) e un attacco a tempo sarebbero in grado di distinguere banalmente se è stato trovato un nome utente (e la password è sbagliata) o non è stato trovato alcun nome utente. Detto semplicemente, non ho idea del motivo per cui qualcuno vorrebbe implementarlo in questo modo. (Il secondo punto è valido, però.)
@Mormegil PostgreSQL fornisce bcrypt. Potrebbe essere soggetto ad attacchi temporali a seconda di come si crea la query.
Potresti farlo in questo modo se il tuo sale per riga è stato generato dal nome utente, ad esempio inserendolo in HMAC con una chiave segreta. Ovviamente per evitare attacchi temporali è necessario assicurarsi che l'hashing della password sia fatto indipendentemente dal fatto che il nome utente esista o meno, ma è banale.
#3
+13
schroeder
2014-07-08 00:50:13 UTC
view on stackexchange narkive permalink

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.

Si Questo. La pagina di registrazione di solito include una qualche forma di CAPTCHA.
Finché il CAPTCHA o un'altra sfida / puzzle arriva _prima_ all'utente viene detto che il nome è già stato preso. Dovrebbe esserci anche un periodo di attesa ragionevole tra i tentativi, ma non così lungo da scoraggiare una persona reale che cerca di creare un account reale.
#4
+6
Kaz
2014-07-08 11:00:55 UTC
view on stackexchange narkive permalink

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.

+1 per la menzione del throttling (limitazione della velocità).
#5
+5
paj28
2014-07-08 13:47:35 UTC
view on stackexchange narkive permalink

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 [email protected] 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.

Per gli indirizzi e-mail, si presume che quando si registra un nuovo account e si fornisce un indirizzo e-mail esistente, non viene visualizzato immediatamente un errore che dice "indirizzo e-mail già in uso"; in caso contrario, non c'è molto vantaggio nell'evitare di rivelarlo nella schermata di accesso, se viene rivelato nella schermata di registrazione. Un modo per evitarlo sarebbe fare in modo che la schermata di registrazione richieda un CAPTCHA prima di dirti se l'indirizzo email che hai fornito è già stato utilizzato o meno.
@D.W. - certo, oppure puoi farlo senza captcha inviando prima un codice di conferma all'indirizzo e-mail, e solo una volta confermato informando l'utente se l'indirizzo è già stato preso.
#6
+4
SilverlightFox
2014-07-08 14:13:02 UTC
view on stackexchange narkive permalink

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.

#7
+2
Bob
2014-07-08 05:59:42 UTC
view on stackexchange narkive permalink

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).

Penserei che su qualcosa come un forum, sarebbe molto più veloce semplicemente scansionare i post pubblici esistenti per scoprire i nomi utente piuttosto che provare a forzarli. Alcuni software per forum includono anche una pagina che elenca i nomi utente per te!
#8
  0
Ahauehuaheuaheuahue
2014-07-08 01:54:52 UTC
view on stackexchange narkive permalink

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.

I Recaptcha possono essere facilmente interrotti da un risolutore di Recaptcha. Questi siti spesso applicano una tariffa bassa e hanno un tasso di precisione di circa il 70%. I captcha (no reCaptcha) sono ancora più facili per un computer. A volte il computer è più bravo di un essere umano, quindi fornisce solo un fastidio ai tuoi utenti.
Prendere una decisione su ciò che funziona per il tuo ambiente va bene, ma devi spiegare perché hai preso quella decisione in modo che gli altri capiscano il suo contesto. I metodi di attenuazione non fanno nulla per risolvere il problema di enumerare gli account utente. Hai sentito che l'enumerazione non era un rischio per il tuo ambiente? Si prega di fornire più che semplici dichiarazioni sprezzanti.
Vedi http://deathbycaptcha.com e http://scraping.pro/decaptcher-review/. Sono d'accordo con tentativi di accesso limitati.
#9
  0
emory
2014-07-08 04:58:23 UTC
view on stackexchange narkive permalink

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.

Questa risposta è priva di senso. Come farebbe qualcosa la creazione di un nuovo utente? Perché hai cresciuto un "uomo di paglia" con il punto 2?
@schroeder per esempio gmail. È possibile utilizzare la pagina di "registrazione" per determinare l'identità di un utente gmail casuale esistente e quindi provare a forzare la password. Ma l'account utente casuale di Gmail avrà probabilmente maggiori privilegi di quelli che puoi creare?
Gli aggressori tendono a forzare gli account per ottenere i dati di QUEL account, non per ottenere semplicemente l'accesso a un sistema. Stai sollevando punti che sono progettati per essere respinti.
@schroeder se sto attaccando un account particolare, a che cosa serve il fatto che il sistema abbia una pagina di registrazione o un messaggio di errore non generico? Ad esempio, la persona che ha violato l'email di Palin conosceva in anticipo il suo nome utente.
Se hai in mente un obiettivo particolare prima dell'attacco, certo, ma anche questo non rientra nell'ambito della domanda. In qualità di aggressore, voglio sapere cosa avrà a disposizione QUALSIASI account. Non come avere accesso al sistema, ma per estrarre tutto ciò che è possibile dal proprio account: PII, informazioni sull'account, password riutilizzate, ecc. Nessuno dei miei punti è nuovo o insolito. Ho la sensazione che ti piaccia essere sprezzante.
#10
  0
Anurag Pathak
2019-07-16 11:49:35 UTC
view on stackexchange narkive permalink

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.



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