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

Se un utente malintenzionato inizia ad attaccare un sito web indovinando combinazioni di nome utente / password come admin / admin, l'utente malintenzionato saprà che il nome utente è valido è restituisce un messaggio di "Password non valida" invece di "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 SQL o bruteforcing della password.

Come altri hanno menzionato, non vogliamo che tu sappia se è stato o meno il nome utente o la password errati, quindi non siamo così sensibili a brute-force o dizionario attacchi ..

Se alcuni siti web volevano che i loro utenti sapessero quale fallire mentre erano ancora nel verde, potevano implementare " honeypot " nomi utente (come amministratore, amministratore, ecc.) Che avvisano gli amministratori del sito Web che qualcuno sta curiosando sul loro sito web. Potresti persino impostare qualche logica per vietare il loro indirizzo IP se tentano di accedere con uno di questi nomi utente "honeypot". Conosco una persona che ha effettivamente un sito Web e inserisce nel codice sorgente un commento HTML come "Poiché continui a dimenticare Richard: Username: cheese Password: Burger123" vicino alla casella di accesso con l'intento di monitorare qualsiasi indirizzo IP che ha tentato di utilizzare quel nome utente / password. Aggiungere logiche di monitoraggio del genere è molto divertente quando sviluppi un sito web.

Naturalmente, la registrazione dei tentativi di accesso non validi e l'aggiunta della logica appropriata per gestire tali indirizzi IP funziona anche. So che alcuni sarebbero in disaccordo con me, ma a seconda del tipo di sito Web, non penso che sia un grosso problema per far sapere all'utente se si aggiungono ulteriori misure di sicurezza per prevenire diversi tipi di attacchi.

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 poi mi chiede di rispondere alle domande di sicurezza (se non ho mai effettuato l'accesso da questo browser su questo computer), attendi che risponda correttamente alle domande di sicurezza, poi mi consenta di vedere la mia immagine / didascalia di sicurezza e di inserire la mia password. Se scrivo il nome utente sbagliato, vedrò qualcosa come "Welcome Bessie / Kareem / Randal!" dove il nome visualizzato è molto raro - sebbene tu sia 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 in modo coerente Frenshelia). Presumo che sia implementato come una sorta di hash non crittografico applicato a qualsiasi nome utente inserito che si associ in modo univoco a un nome utente su una lunga lista di nomi abbastanza rari. Ciò consente agli utenti legittimi di sapere se hanno digitato il nome utente sbagliato (come anche se si ha un nome insolito come Bessie, è molto improbabile che il nome utente errato sia stato indovinato in modo casuale per tornare al proprio nome comune), senza rendere evidente a chi prova per trovare account casuali che il nome utente non esiste.

Per inciso: non sono particolarmente interessato alle domande sulla sicurezza / alla parte dell'immagine di sicurezza, che sembra essere al confine con il teatro della sicurezza. Un attaccante sofisticato che esegue un attacco man-in-the-middle (MITM) (ad esempio, dopo aver installato certificati falsi nel browser Web e lo spoofing DNS / ARP per indirizzare il tuo accountbank.com al proprio indirizzo IP) potrebbe attendere finché non si prova a registrare nel sito, quindi avere uno script automatico accedere sul proprio computer al sito reale, ottenere le domande di sicurezza, visualizzare le domande di sicurezza prescelte, rimandare indietro le risposte al sito dal proprio browser, attendere per ottenere la sicurezza immagine, restituisci l'immagine secuirty all'utente, quindi attendi che tu inserisca la password dalla loro fine, a quel punto in cui usano la password per accedere come te e fare cose maligne. Le domande + l'immagine rendono il processo più difficile che avere tutto il tempo del mondo per raccogliere tutte le immagini di sicurezza per una varietà di nomi utente attaccati trasformandolo in un attacco che deve essere eseguito in tempo reale e che potrebbe lasciare una firma sospetta .

Altre risposte forniscono una buona conoscenza delle ragioni di sicurezza alla base di questo comportamento. Anche se sono corretti, sono abbastanza sicuro che almeno alcuni siti web abbiano la routine di autorizzazione programmata nel modo in cui è impossibile dire cosa è stato sbagliato - login o password.

Query di esempio:

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

Ciò restituirà 1 al tentativo di registrazione riuscito e 0 se non ci sono utenti con tale nome o questo utente ha una password diversa. Non c'è modo di dire quale parte della condizione ha fallito. Quindi, quando si tratta di visualizzare un programmatore di messaggi di errore, ti dico onestamente che qualcosa non va e lui non è veramente sicuro di cosa sia esattamente.

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

C'è, tuttavia, un'altra tecnica interessante che può essere applicata per eseguire un user enumeration attack (e altro). Si chiama Timing attack . L'autore dell'attacco misura semplicemente il tempo di risposta per la richiesta di autenticazione e la sua differenza tra un accesso valido e uno non valido.

1. Attacchi temporizzati su scala nanoseconda per applicazioni PHP: è il momento di prenderli seriamente?
   link

2. Una lezione sugli attacchi di temporizzazione
   link

3. Confronto tra stringhe di tempo costante in PHP per prevenire attacchi di temporizzazione
   link

Il mio punto è che un tale messaggio non è sufficiente se vuoi proteggere la tua applicazione da questo tipo di minaccia.

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

Oltre a tutte le grandi risposte già fornite, esiste un principio di sicurezza generico che afferma che non è necessario fornire informazioni indesiderate a utenti non autorizzati. Cioè se hai la possibilità di rispondere o "i tuoi dati di autenticazione non sono validi" o di spiegare quale parte non è valida, devi sempre scegliere la prima. Alcuni attacchi crittografici molto pericolosi sono basati sulla più piccola quantità di informazioni di errore fornite dall'implementazione che cercano di essere "utili" - vedi Attacchi oracle di riempimento . Quindi è una buona idea optare sempre per il più piccolo possibile di informazioni divulgate all'entità non autorizzata - cioè, se il suo nome utente / password non è buono, rispondi sempre "nome utente / password non buono", e non rivelare mai più dati. Anche se in un caso specifico (come gmail dove il nome utente è pubblico) non è importante, è una buona pratica adottare per impostazione predefinita.

Diciamo che inserisci un nome utente casuale e una password ugualmente casuale (ti basta annotare 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 succederà dopo ... mayhem tra gli utenti autentici come ottenere i nomi di accesso sono abbastanza facili.

Fornire una risposta ambigua è utile per prevenire l'attacco enumerazione utente .

In alcuni casi, l'utente malintenzionato non deve compromettere l'account utente. Le informazioni che l'utente ha dell'account sono sufficienti senza altre azioni. Ad esempio, sono preziose informazioni per il commercio che il cliente ha un account nel negozio online competitivo.

Apprezzo le varie risposte di cui sopra come dicono di più, ma a volte le applicazioni non sono consapevoli di ciò che è sbagliato UserName o Password. In caso di autenticazione basata su token, specialmente per implementare SSO (Single Sign On) ad es. IBM Tivoli Access Manager la tua applicazione riceve un token con successo o ottiene un errore.

se il login è un indirizzo email, è facile scoprire che una persona è registrata su 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:)