Dovrebbe essere registrato un nome utente non valido?

Devi registrare nomi utente non validi.

Considerare lo scenario in cui un utente malintenzionato sta eseguendo un attacco bruteforce online contro il proprio servizio utilizzando un dizionario di nome utente e password. L'utente malintenzionato non sta eseguendo un attacco mirato contro un particolare account sul tuo sistema, ma sta provando nomi utente casuali.

Se non si registrano nomi utente non validi, c'è la possibilità che un attacco bruteforce possa passare inosservato. Se si registrano nomi utente non validi e informazioni come gli indirizzi IP, vi è una maggiore possibilità di essere in grado di riconoscere un attacco bruteforce contro il proprio sistema che consente di intraprendere le azioni appropriate per fermare l'attacco.

Sì. D'altro canto, non si desidera che il file di registro contenga potenzialmente le password, cosa che succederebbe se qualcuno inserisse il login e inviasse la password al posto del nome utente.

Quello che penso potrebbe essere un compromesso valido potrebbe essere il log:

• tentativi con nomi utente validi e password non valide, registrazione del nome utente ma non della password.
• tentativi con nomi utente non validi (che potrebbero essere password o qualsiasi altra cosa), registrando il nome utente come "INVALID".

La logica è che diversi tentativi con un singolo nome utente valido ti diranno di una possibile bruteforcing contro quel nome utente; uno sciame di tentativi contro il nome utente INVALID avverte di un attacco "nome utente con password ovvia" su larga scala, che, se si dispone di una politica password corretta, è irritante ma innocuo. Tanto più che i tentativi contro utenti noti.

È ipotizzabile che qualcuno stia tentando di forzare un singolo nome utente non valido; se questo è un problema, puoi registrare nomi utente non validi come hash (parziale e / o salato). Il valore di queste informazioni in chiaro, anche se catturate da parti ostili, sarebbe essenzialmente nullo.

Un numero molto piccolo di tentativi sul nome utente NON VALIDO può essere dovuto a errori di ortografia dei propri nomi da parte degli utenti o alla digitazione della password al posto del nome; o paranoici che intenzionalmente bloccano il loro primo accesso credendo che questo sia protetto contro l'acquisizione di credenziali.

Specialmente se seguito rapidamente da un login valido dallo stesso indirizzo (a meno che non si tratti di un sistema che maschera una grande rete ...), un errore di autenticazione occasionale di questo tipo potrebbe essere considerato rumore e ignorato.

(Potresti inoltre distinguere un piccolo insieme di "nomi validi non validi" come informazioni , admin *, amministratore , ospite , se volevi, ma probabilmente è eccessivo)

Inoltre, per i veri paranoici, potresti riempire tutti i nomi utente validi e la stringa "INVALID" deve essere la stessa, a lunghezza fissa (diciamo ... 20 caratteri?). Se per caso un utente malintenzionato potesse osservare da remoto la crescita del file di registro, non sarebbe in grado di stabilire se esistesse o meno un nome utente nel sistema.

Segui il link makerofthings7 fornito come commento, dato che aveva un sacco di dettagli su come fermarlo in primo luogo, ma dovresti comunque registrare tutti i tentativi.

Why would it not be sufficient for an authentication system to log only invalid authentication attempts for valid user names?

Un tentativo di accesso non valido potrebbe indicare un possibile attacco. Se registri solo quelli con nomi utente validi, non vedrai tutti gli attacchi che potrebbero aiutarti a contrastare meglio il tentativo se è distribuito o potrebbe fornirti qualche altra informazione utile.

In rari casi, se il log è esposto / accessibile, l'utente malintenzionato potrebbe utilizzare questo per enumerare nomi utente validi / non validi (test A / B su ogni accesso, anche se i registri sono esposti pubblicamente ...).

Il problema principale è che la password potrebbe essere registrata. Ciò potrebbe anche verificarsi con una bassa probabilità se l'utente immette la password nel campo del nome utente, ma inserisce comunque del contenuto nel campo della password.

In potrebbe essere meglio crittografare l'intero registro o almeno la porzione del nome utente (o qualsiasi altra informazione personale inclusa) quando archiviata. Qualsiasi SIEM, ecc. Può ancora essere correlato se la crittografia è sempre la stessa per un determinato valore. Poiché è una buona idea memorizzare tutti i tentativi non validi, la crittografia ti consente di mantenere un'esposizione limite delle password.

È possibile registrare il valore crittografato dei nomi utente non validi.

Se qualcuno sta eseguendo un attacco di forza bruta da più indirizzi IP, puoi / devi identificarlo analizzando il traffico sul tuo server web, non guardando i nomi utente registrati. Questo può essere fatto a livello di applicazione. Se ricevi un numero insolito di richieste di accesso da un indirizzo IP, puoi semplicemente bloccare quell'indirizzo IP (per un periodo che ritieni appropriato). Altrimenti potresti trovare il tuo server web compromesso molto prima di avere la possibilità di guardare i nomi utente / password registrati.

Ora supponiamo che un utente legittimo inserisca accidentalmente la sua password nella casella del nome utente. Se memorizzi il testo non elaborato, il nome utente (password) registrato può essere letto da un intruso (supponiamo che un intruso abbia in qualche modo ottenuto l'accesso ai tuoi file di dati). Il tuo obiettivo è rendere i dati illeggibili dall'intruso in questa situazione. Questo è quando la crittografia è utile.

Se si utilizza un DBMS, la crittografia può essere eseguita dal sistema di database. Ad esempio è possibile crittografare le tabelle / colonne che memorizzano i nomi utente e hash le password.

Se si memorizzano queste informazioni in, diciamo un file CSV, questa crittografia può essere eseguita a livello di applicazione. Se sei in grado di utilizzare la crittografia a chiave pubblica, la tua vita sarà facile. L'applicazione può semplicemente crittografare i valori immessi utilizzando la chiave pubblica e tu (o chiunque conosca la chiave privata) può decrittografarli con la chiave privata - dovrebbe essere abbastanza facile mantenere la chiave privata al sicuro. Se devi utilizzare la crittografia a chiave simmetrica, ci sono diversi modi per memorizzare la chiave segreta in modo sicuro (fai una ricerca online). Potrebbe non essere sicuro e semplice come utilizzare la crittografia a chiave pubblica, ma è molto meglio che mantenere il testo non elaborato, giusto?

Ricorda che l'obiettivo è rendere intrusioni costose, non rendere il tuo sistema immune al 100% ... perché non è semplicemente pratico.

Penso che questa domanda sia guidata dalla definizione del caso e varia in base ai requisiti per l'analisi. Considera questo,

An attacker using dictionary brute force attack; can lock legitimate users (considering) he keeps a dictionary that is well-social engineered for his attack environment. In this attacker is abusing the account lockout policy.

Ora, nello scenario di cui sopra c'era un sistema honeypot (che eseguiva un servizio telnet vulnerabile) puoi imparare molto sul modo in cui l'utente malintenzionato usa il dizionario. Se gli utenti nel dizionario corrispondono agli elenchi di organizzazioni, è probabile che tu possa avvisare  amministratori di sistema per cambiare nome utente.

come alcuni calcoli matematici e statistiche possono aiutare ad analizzare la tendenza, per esempio i dati dicono che l'attaccante sta colpendo il nome utente corretto dopo l'80% dei tentativi falliti dopo ogni cinque minuti. Questo numero ti offre il periodo di sicurezza o di grazia per l'azione.