Questa è una considerazione tra sicurezza e usabilità, e quindi non c'è davvero una risposta giusta qui. Quindi ecco la mia opinione.

Se puoi mantenere segreti i nomi utente, fallo. In questo caso non c'è modo di capire se esiste un nome utente e il login reagisce allo stesso modo indipendentemente dal fatto che un utente esista o meno. Tieni presente che questo significa anche impiegare la stessa quantità di tempo per restituire un messaggio di errore.

Questo comportamento potrebbe non essere possibile. Ad esempio, se gli utenti possono registrarsi e scegliere il proprio nome utente, è necessario avvisarli quando un nome utente esiste già nel sistema. In tal caso, rendere il login il più semplice possibile fornendo il messaggio di errore più dettagliato. Se qualcuno riesce a capire se un utente esiste utilizzando la funzione di registrazione, non serve nasconderlo al login.

Non è l'unica linea guida OWASP che non è seguita dai grandi giocatori. OWASP si concentra spesso sulla sicurezza e ignora l'usabilità. Può essere una valida scelta di progettazione se combinato con una politica delle password decente, protezione brute-force (lockout, captcha, ..), MFA, monitoraggio dei tentativi di accesso non riusciti, ecc.

Prendi in considerazione l'enumerazione degli utenti non è solo il problema di essere in grado di indovinare gli account utente che puoi successivamente forzare per l'autenticazione. Alcuni siti dovrebbero proteggere la privacy dei propri utenti (adulti, partiti politici, appuntamenti, ...). Se desidero controllare se il mio capo utilizza un sito web per adulti, posso utilizzare in modo improprio una vulnerabilità dell'enumerazione degli utenti per sapere quali siti sta utilizzando.

Non puoi impedirlo. (A meno che tu non sia pronto a sacrificare una quantità significativa di usabilità.)

L'enumerazione degli utenti può essere indesiderabile e ci sono effettivamente implicazioni sulla sicurezza (ad esempio, se un utente malintenzionato scopre che esiste un account valido denominato admin a cui potrebbe tentare di accedere). Ma per i siti di grandi dimensioni è qualcosa che non puoi impedire che accada.

Anche se durante l'accesso non riveli che un utente non esiste, dovrai eventualmente avvisare i nuovi utenti quando tentano registrare un nome già preso o con un indirizzo e-mail già utilizzato .

Non esiste un modo semplice per aggirare questo:

La sicurezza è relativa. È leggermente più sicuro non fornire informazioni sull'esistenza o meno dell'account. Ma ciò non significa che non sia sicuro fornire tali informazioni. È solo meno sicuro, e solo leggermente.

Questo è particolarmente vero negli esempi che dai; ci sono altri modi per trovare i nomi degli account, quindi non c'è alcun vantaggio nel cercare di nascondere se l'account esiste o meno.

Come con qualsiasi forma di sicurezza tramite oscurità, nascondere l'account names è un controllo di sicurezza debole e sono necessari altri controlli.

Sono d'accordo con la risposta di @ Silver, ma voglio espandere. Tieni a mente il contesto; le linee guida OWASP sono intese come regole pratiche per gli sviluppatori che non sono esperti di sicurezza. Se una società di sviluppo software ha un team di architetti di sicurezza di talento, non è necessario che segua ciecamente le regole pratiche fintanto che comprendono l'intenzione dietro le regole e mitigano i rischi in altri modi.

Analogia: dovresti cambiare l'olio della tua auto ogni 3 mesi o 5.000 km, ma i meccanici spesso spingono più a lungo quando sanno che le loro abitudini di guida sono state buone. E va benissimo.

Per quanto riguarda le specifiche qui, non sono un esperto di vuln di enumerazione degli utenti, né sono al corrente del motivo per cui Google e Microsoft hanno preso le decisioni che hanno fatto, ma presumo che hanno in atto limiti di velocità e blacklist per prevenire attacchi di enumerazione degli utenti su larga scala e hanno altrimenti deciso che la comodità dell'utente vale il rischio aggiuntivo.

Probabilmente è troppo difficile dire che violano le linee guida OWASP, perché per applicazioni e servizi come Google, Microsoft, devono essere il più possibile "conformi agli utenti".

Inoltre, hanno tutti o offrire protocolli 2FA.

Lo scopo di non divulgare l'identificatore utente attivo è impedire l'enumerazione di un gran numero di account.

A rigor di termini, potresti proteggerti consentendo account duplicati, ma questo è un progetto terribile e ti porterà a tutti i tipi di problemi.

Un altro modo per farlo è assegnare agli utenti un identificatore, costruendone uno inutilizzato. Ma questa è un'esperienza di usabilità così scarsa che potrebbe non valerne la pena *.

Il modo sensato per mitigare il rischio è implementare qualsiasi anti -funzione di enumerazione - ad esempio, un captcha di buona qualità, per rallentare qualsiasi tentativo di enumerazione. Quindi il design è ragionevolmente sicuro.

Il rischio residuo è quindi che lasci aperta la verifica di un account di valore molto elevato, ad esempio barack .obama @ gmail.com. Quindi mitighi questo rischio implementando anche un controllo contro i tentativi di cracking delle password, ecc.

* Salzer e Shroeder, The Protection of Information in Computer Systems, Section IA3 ) h) Accettabilità psicologica: è essenziale che l'interfaccia umana sia progettata per la facilità d'uso, in modo che gli utenti applichino regolarmente e automaticamente i meccanismi di protezione in modo corretto. Inoltre, nella misura in cui l'immagine mentale dell'utente dei suoi obiettivi di protezione corrisponde ai meccanismi che deve utilizzare, gli errori saranno ridotti al minimo. Se deve tradurre la sua immagine delle sue esigenze di protezione in un linguaggio di specifica radicalmente diverso, commetterà errori.