it-swarm.dev

"Nome utente e / o password non validi" - Perché i siti Web mostrano questo tipo di messaggio invece di informare l'utente quale era sbagliato?

Supponiamo che un utente stia accedendo a un sito tipico, inserendo il nome utente e la password e digiti male uno dei loro input. Ho notato che la maggior parte dei siti, se non tutti, mostrano lo stesso messaggio (qualcosa del tipo "Nome utente o password non validi") nonostante un solo input sia errato.

A me sembra abbastanza facile comunicare all'utente quale input era sbagliato e questo mi ha fatto chiedermi perché i siti non lo fanno. Quindi, c'è un motivo di sicurezza per questo o è solo qualcosa che è diventata la norma?

103
bobble14988

Se un utente malintenzionato inizia ad attaccare un sito Web indovinando combinazioni comuni di nome utente/password come admin/admin, l'utente malintenzionato saprebbe che il nome utente è valido se restituisce il messaggio "Password non valida" anziché "Nome utente o password non validi".

Se un utente malintenzionato sa che il nome utente è valido, potrebbe concentrare i suoi sforzi su quel particolare account usando tecniche come iniezioni di SQL o forzando la password.

128
user10211

Come altri hanno già detto, non vogliamo che tu sappia se era o meno il nome utente o la password che era sbagliato, quindi non siamo sensibili a forza bruta o dizionario attacchi ..

Se alcuni siti Web volessero far sapere ai loro utenti quale non è riuscito pur rimanendo nel verde della sicurezza, potrebbero implementare " honeypot " nomi utente (come amministratore, amministratore, ecc.) Che avviserebbero il sito Web ammette che qualcuno sta curiosando nel loro sito web. Potresti anche impostare una logica per vietare il loro indirizzo IP se tentassero di accedere con uno di quei nomi utente "honeypot". Conosco una persona che in realtà aveva un sito Web e inseriva nel proprio codice sorgente un commento HTML del tipo "Dato che continui a dimenticare Richard: Nome utente: password del formaggio: Burger123" vicino alla casella di accesso con l'intento di monitorare qualsiasi indirizzo IP che ha tentato di utilizzare quel nome utente/password. L'aggiunta di una logica di monitoraggio del genere è molto divertente quando si sviluppa un sito Web.

Naturalmente, anche la registrazione di tentativi di accesso non validi e l'aggiunta della logica appropriata per gestire quegli indirizzi IP funzionano. So che alcuni non sarebbero d'accordo con me, ma a seconda del tipo di sito Web, non penso che sia un affare troppo grande per far sapere all'utente fintanto che aggiungi ulteriori misure di sicurezza per prevenire diversi tipi di attacchi.

24
ROFLwTIME

La mia implementazione sicura preferita di questo è fatta da una banca che uso. Se digito correttamente il mio nome utente, verrà visualizzato "Benvenuto Jimbob!" e quindi mi chiede di rispondere alle domande di sicurezza (se non ho mai effettuato l'accesso da questo browser su questo computer), attendere che risponda correttamente alle domande di sicurezza, quindi mi vedrà la mia immagine/didascalia di sicurezza e inserire la mia password. Se digito il nome utente sbagliato, vedrò qualcosa come "Welcome Bessie/Kareem/Randal!" dove il nome visualizzato è molto raro - anche se sarai sempre lo stesso nome per lo stesso nome utente (di solito non sono sicuro tra uno o due nomi utente; e quello sbagliato mi chiama costantemente Frenshelia). Presumo che sia implementato come una sorta di hash non crittografico applicato a qualsiasi nome utente immesso che si associa in modo univoco a un nome utente in un lungo elenco di nomi abbastanza insoliti. Ciò consente agli utenti legittimi di sapere se hanno digitato un nome utente errato (come anche se si dispone di un nome non comune come Bessie; è molto improbabile che il nome utente errato indovinato casualmente ritorni al tuo nome non comune specifico), senza renderlo ovvio alle persone che provano per trovare account casuali che il nome utente non esiste.

A parte questo: non mi piacciono particolarmente le domande sulla sicurezza/la parte dell'immagine della sicurezza, che sembra rasentare il teatro della sicurezza. Un aggressore sofisticato che sta eseguendo un attacco man-in-the-middle (MITM) (ad esempio, dopo aver installato certificati falsi nel tuo browser Web e lo spoofing DNS/ARP per indirizzare yourbank.com al loro indirizzo IP) potrebbe attendere fino a quando non provi ad accedere nel sito, quindi fai in modo che uno script automatico acceda sul loro computer al sito reale, ricevi le domande di sicurezza, ti mostri le domande di sicurezza scelte, rispedisca le risposte al sito stesso dal loro browser, attendi di ottenere la sicurezza immagine, restituire l'immagine di sicurezza all'utente, quindi attendere l'inserimento della password dalla loro estremità, a quel punto usano la password per accedere come te e fare cose dannose. Concesso le domande + immagine rende il processo più difficile che avere tutto il tempo nel mondo per raccogliere tutte le immagini di sicurezza per una varietà di nomi utente attaccati trasformandolo in un attacco che deve essere fatto in tempo reale e forse lascia una firma sospetta .

18
dr jimbob

Altre risposte forniscono una buona visione dei motivi di sicurezza alla base di questo comportamento. Anche se sono corretti, sono abbastanza sicuro che almeno alcuni siti web hanno appena programmato la routine di autorizzazione nel modo in cui è impossibile dire cosa non va - login o password.

Query di esempio:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

Ciò restituirà 1 in caso di tentativo di registrazione riuscito e se non esiste un utente con tale nome o questo utente ha una password diversa. Non c'è modo di sapere quale parte della condizione è fallita. Quindi, quando si tratta di visualizzare un programmatore di messaggi di errore, onestamente ti dice che qualcosa non va e non è davvero sicuro di cosa sia esattamente.

Personalmente ho visto query simili in alcuni siti Web basati su PHP, quindi sono abbastanza sicuro che parte del motivo provenga dal modo in cui il processo di autenticazione è codificato, davvero.

13
Dyppl

Vi è, tuttavia, un'altra tecnica interessante che può essere applicata per eseguire un user enumeration attack (E altro). Si chiama Timing attack. L'aggressore misura semplicemente il tempo di risposta per la richiesta di autenticazione e il modo in cui differisce tra un login valido e uno non valido.

  1. Attacchi temporizzati su scala dei nanosecondi su applicazioni PHP: è ora di prenderli sul serio?
    http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

  2. Una lezione sugli attacchi ai tempi
    http://codahale.com/a-lesson-in-timing-attacks/

  3. Confronto di stringhe di tempo costante in PHP per prevenire attacchi di temporizzazione
    https://codereview.stackexchange.com/questions/13512/constant-time-string-comparision-in-php-to-prevent-timing-attacks

Il mio punto è che un tale messaggio non è sufficiente se si desidera proteggere l'applicazione da questo tipo di minaccia.

8

Il motivo di sicurezza dietro è altrimenti diventa molto più facile trovare nomi utente validi.

5
Lucas Kauffman

Oltre a tutte le ottime risposte già fornite, esiste un principio di sicurezza generico che afferma che non si dovrebbero fornire informazioni non richieste a utenti non autorizzati. Cioè se hai la possibilità di rispondere o "i tuoi dati di autenticazione non sono validi" o spiegando quale parte non è valida, dovresti sempre scegliere la prima. Alcuni attacchi crittografici molto cattivi si basano sulla più piccola quantità di informazioni di errore fornite dall'implementazione cercando di essere "utili" - vedi Padding Oracle attack . Quindi è una buona idea optare sempre per la più piccola parte possibile di informazioni divulgate all'entità non autorizzata - vale a dire, se la sua combinazione nome utente/password non è buona, rispondi sempre "nome utente/password non è buono" e non divulgare più dati. Anche se in un caso specifico (come gmail in cui il nome utente è pubblico) non è importante, è una buona pratica adottare di default.

5
StasM

Supponiamo che tu inserisca un nome utente casuale e una password altrettanto casuale (basta notare quale password inserisci). Ora le password possono essere comuni tra gli n utenti. Quindi, se il sito web dice che la password è corretta ... allora sai cosa segue dopo ... il caos tra gli utenti reali in quanto ottenere i nomi di accesso è abbastanza facile.

4
aayush anand

Fornire una risposta ambigua è utile per prevenire attacchi enumerazione utente .

In alcuni casi l'attaccante non ha bisogno di compromettere l'account utente. Le informazioni di cui l'utente dispone dell'account sono sufficienti senza altre azioni. Ad esempio, sono informazioni preziose per il commercio che i loro clienti hanno un account su un negozio web competitivo.

4
Jakub Šturc

Apprezzo varie risposte sopra come dicono di più, ma a volte anche le applicazioni non sono consapevoli di ciò che è sbagliato UserName o Password. Nel caso di un'autenticazione basata su token appositamente per implementare SSO (Single Sign On) ad es. IBM Tivoli Access Manager l'applicazione riceve un token corretto o riceve un errore.

4
Niks

se il login è un indirizzo e-mail, è facile scoprire che una persona è registrata in un sito Web - Potrei non volerlo >> A volte le persone usano la password reale dell'account e-mail per i siti Web che registrano quando usano l'id e-mail come ID di accesso :)

3