Le password vengono inviate in chiaro a causa di un errore dell'utente nel digitarlo nel campo username

Un pensiero è di non consentire l'invio del modulo se non c'è un valore nella casella della password. Generalmente se inseriscono accidentalmente la password nel nome utente, probabilmente non ci sarà nulla nella finestra di dialogo della password.

Vale la pena notare che questo non deve essere fatto semplicemente lato client, ma potrebbe anche essere fatto su un server purché il trasporto utilizzato sia sicuro e l'input non venga registrato fino a dopo aver passato un controllo sul campo password non essere vuoto.

Supponendo che l'applicazione back-end e SIEM debbano visualizzare i tentativi di accesso non riusciti a varie applicazioni (e quindi mostrare il messaggio di errore "Utente P @ $$ w0rd non valido"), non sarà banale interromperlo.

Tuttavia, assicurando che tutte le applicazioni che inviano dati sensibili inclusi nomi utente e password implementino HTTPS (HTTP crittografato tramite SSL) è un buon modo per garantire che i dispositivi di rete e chiunque sulla rete non possano ottenere la password inserita erroneamente nel casella nome utente!

Quindi il problema è che non vuoi che gli analisti vedano le password nei file di registro sensibili?

Attenzione: Anche se dovessi usare Javascript, non tratta i dati della password che sono archiviati sul tuo disco in testo normale.

A better solution is to preprocess the logs before the analysts see them and redact information in the logs.

Puoi effettuare questo filtraggio riga per riga se autorizzi le linee o altre linee in lista nera. Ad esempio:

Puoi autorizzare i nomi utente quando compaiono in un file di registro che

• Hai uno schema ([az] + numero) o ([az] + periodo + [az])
• include un nome di dominio seguito da una barra "\" per ambienti AD
• appaiono più volte
• Può essere lavato contro una directory LDAP di nomi utente noti prima che gli analisti lo vedano

Identifichi anche le password per la blacklist:

• La politica password segue spesso un modello (un simbolo, superiore / inferiore, x caratteri ...)

È possibile utilizzare questa conoscenza per creare un detergente per i dati dei registri personalizzato per proteggere le informazioni che non si desidera che gli analisti possano vedere.

Che aspetto ha una linea filtrata?

Puoi semplicemente cancellare nomi utente discutibili tagliandoli e assegnandoli a un ID umano e archiviandoli in un luogo sicuro:

 eb574b236133e60c989c6f472f07827b   Redact1
 7e67b89a695bfbffc05b7ed2c38f927f   Redact2
 ..etc

Gli analisti possono vedere se una particolare voce si sta ripetendo all'infinito se l'hash si ripete in frequenza.

Il metodo di hashing esatto (o metodo di crittografia) che si sceglie è soggetto a rischi poiché questo "database hash" conterrà informazioni di alto valore. E la semina (per sua natura) impedirà l'analisi della frequenza che può o non può avere valore per te.

Posso solo identificare tre problemi con quello di cui stai discutendo.

1. Gli utenti non inseriscono le informazioni correttamente.
2. Gli analisti possono discernere le password dai log.
3. Le password vengono inviate in chiaro e sono suscettibili alle intercettazioni man-in-the-middle

Secondo me, questo è abbastanza semplice da risolvere.

1. Accetta errore utente, a malincuore .
2. Non registrare nomi utente non validi, ma registra tentativi falliti e IP.
3. Non inviare nomi utente in testo chiaro. Utilizza la tecnologia come HTTPS o usa javascript per codificare il testo in chiaro (ad esempio ROT13).

Esempio di registro di un login fallito e poi un tentativo riuscito.

[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100

Leggendo altre risposte, vorrei includerlo.

• Convalida tutti i campi prima dell'invio.
• Prendere in considerazione la possibilità di suddividere il modulo tra più pagine, come ha detto Eric G.

Una soluzione che ho visto implementare alcune banche, almeno nelle app Web, è avere un accesso di due pagine.

1. Nella prima pagina accetta solo il nome utente
2. Nella pagina successiva del processo richiedi la password e rispondi solo al nome utente in modo che non sia un campo modificabile

Pertanto l'unico input sulla seconda pagina dovrebbe essere la password. Dato che l'utente sa che è necessario cancellare la prima pagina con un nome utente, sanno che devono cancellare quel cancello, quindi l'unica opzione nella seconda pagina è la password.

Se puoi implementare questo flusso di lavoro, aiuterà a focalizzare gli utenti su ciò che stanno digitando e quando.

Inoltre, considerando la registrazione: forse è possibile modificare la registrazione per non includere le credenziali effettive?

Ad esempio, in caso di accesso riuscito, utilizzare l'id della chiave primaria invece di ripetere l'input: "L'utente con id: '2342342' ha tentato l'accesso", quindi "L'utente con ID '2342342' ha fornito correttamente una password ".

Se esegui una ricerca e il nome utente non è presente, qualcosa come "Utente dall'indirizzo IP" 192.168.0.10 "ha tentato di accedere con un ID utente non valido".

Questo sarebbe il log del tuo livello dell'app. I log del server Web possono includere parametri di query, quindi potrebbe essere un po 'più difficile da indirizzare o forse è possibile inserire qualche tipo di filtro proxy tra l'azione e quando il log è scritto per redigere il contenuto del registro in base a determinate regole. Questo sarebbe specifico per la piattaforma, ma potrebbe sembrare possibile su Apache .

Come controllo secondario, limita l'accesso in lettura ai vari file di registro che stai elaborando.

In generale, tutti i codici client sono abbastanza intelligenti per gestire gli errori di base

1. ID utente e / o password mancanti
2. La password non corrisponde alle Linee guida

Quindi, in ogni caso, quando vedi ancora queste voci nel registro,

User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]

Nessuno dei client Validation ha funzionato e il Sistema ha finito per inviare la password non criptata sulla rete. Quindi cosa c'era nel campo Password? Sicuramente non vuoto dato che la validazione del client fallirebbe. Mi deve qualcosa di diverso dalla password

Quindi crea un'autenticazione a due passaggi

1. First Pass, invia tutti i dettagli crittografati inclusa la password al server. Verifica se il campo Password è vuoto.
2. Primo passaggio, verifica che la password corrisponda alle linee guida Errore in caso contrario.
3. First Pass, quindi controlla se la password è presente nel tuo DB. Se non Error Out.
4. Invia una risposta RPC al client e lascia che invii l'ID utente e la password ora.
5. Ora esegui il processo di autenticazione

L'essenza di questo processo è

1. Riduci al minimo il rischio. Nota, non puoi eliminare il rischio per Zero
2. Non fidarti del Cliente.

E infine, ricontrolla la tua interfaccia da un esperto di UX. Potrebbe essere, la tua interfaccia ha qualche difetto che fa sì che gli utenti inseriscano la password nel campo ID.

Da ciò che descrivi della tua architettura, questo è irrealizzabile, ma a mio avviso la soluzione corretta è: non inviare il nome utente in chiaro e non registrare i nomi utente dei tentativi di accesso non riusciti. Il solo posto dove username e password dovrebbero andare è il sottosistema che controlla la password; fino a quando ciò non si verifica, il nome utente è non autenticato, dati arbitrari - chiunque abbia accesso al modulo di accesso, che in un'applicazione Web è l'intera Internet, può digitare tutto ciò che desidera comunque spesso lo desidera - e quindi ti dice molto poco di interesse. (A meno che il tuo modulo di accesso non sia esposto a Internet.)

this would probably eliminate a lot of the log analysis for not being able to tell who did what....?

Dato un nome utente senza la password corretta, non sai che la richiesta proviene effettivamente da quell'utente , quindi non sai ancora chi ha fatto il login tentativo.

Il problema generale è l'autenticazione basata su password. Ogni negozio mom-and-pop insiste nell'avere un'autenticazione con password. Questo è stupido.

Lascia che qualche altro fornitore di identità faccia il duro lavoro per proteggere le credenziali. Fai lo stesso di StackOverflow: consenti l'autenticazione con OpenID, Gmail, ecc.

I tuoi utenti ti ringrazieranno per non aver ancora bisogno di un'altra password da qualche parte.

Il javascript lato client sembra ragionevole.

Il campo per la verifica della password non è vuoto, prima dell'invio. Verifica che il nome utente sia in una forma valida. Soprattutto elegante è qualcosa in cui il nome utente è richiesto per essere un indirizzo email. È inoltre possibile proibire che la password al proprio set di password / meccanismo di modifica non sia sotto forma di un indirizzo email. Quindi controlla semplicemente che il nome utente sia sotto forma di un indirizzo email valido prima di inviare il modulo. Questo potrebbe essere fatto in modo simile con dire caratteri speciali o numeri. (Ad es., Numeri / caratteri speciali sono richiesti nelle password ma vietati dai nomi utente).

Inoltre, utilizza un SSL di libreria aggiornato per tutti gli invii di moduli (questo dovrebbe essere fatto per evitare che gli intercettatori della rete ascoltino). Richiedere autorizzazioni elevate per leggere questi registri (ad esempio, l'account del server web può scrivere su questi registri, ma solo root può leggerli). Non appena la password fallisce la fase di autenticazione, non propagare il nome utente ad altri sistemi. (Usa anche SSL tra sistemi interni distinti per evitare intercettatori di rete).

Mi piace l'approccio che la mia attuale azienda prende in questo problema: se si digita la password nella casella sbagliata, un sistema automatico fa scadere immediatamente la password. Pertanto, l'utente deve modificare la propria password e la password presente nel log non è più vulnerabile.

Naturalmente, questo non è ancora l'ideale se l'utente usa ancora quella password per un altro sistema, ma si spera che sarà costretto a cambiare la propria password per rendere un utente più consapevole dei possibili rischi per la sicurezza.

Per lo più la risposta più facile è la risposta giusta. Ora notiamo che ogni indirizzo email ha un segno "@" appena prima del nome del dominio. Rendere "@" una chiave NON ACCETTABILE in password rende la soluzione abbastanza ovvia. Se il nome utente NON ha @ e ALL USERNAMES sono indirizzi email, quindi registra solo quelli che hanno almeno @ in essi.

Ora se il nome utente DONOT ha "@", probabilmente potrebbe far arrabbiare alcuni utenti, ma questa è una soluzione chiara. Questo è avere UN SOLO carattere speciale che viene PRIMA di una password. Proprio come TUTTI gli USERNAME che sono account di posta elettronica hanno un formato. Tutte le risposte hanno un carattere speciale all'inizio o alla fine, qualunque sia. Quindi, quando l'utente sta inserendo una password, gli comunichi che ha bisogno di inserirla.

Terza soluzione è quella CODIFICA COLORE. Rendi il nome utente Campo Giallo e Password Campo ROSSO. Il rosso normalmente attira la tua attenzione perché è usato per cose sensibili. Quindi, anche se stanno guardando la tastiera, l'IMPOSTAZIONE MOLTO VIZIOSA è che le password sono rosse. Quindi, in pratica, il campo di testo E L'etichetta della password è rossa preferibilmente in una casella separata e l'etichetta Nome utente e il campo di testo TUTTO GIALLO.

Perché non rispondere con questo?

That username does not exist

Quanto controllo hai sulla gestione del server ricevente? Sembra che la soluzione che un utente ha proposto sopra, per cancellare sia il nome utente che la password, sarebbe praticabile in un paio di modi:

Metodo 1 (che richiede JavaScript): Hash sia nome utente che password. Nel tuo database, memorizza i nomi utente con hash, quindi esegui la ricerca dell'autorizzazione utilizzando quel campo. Questo sarebbe l'ideale se hai il controllo sul modo in cui i dati sono trattati sul tuo server, ma non ne controlli la capacità di registrazione.

Metodo 2 (non richiede JavaScript): Ricevi username in chiaro come al solito, ma convertilo in un hash come nel metodo 1 dopo averlo ricevuto sul server. Quando il tentativo fallisce, registra l'hash, non il nome utente. I log saranno comunque utili (un po 'meno utili se ispezionati in modo puntuale), poiché ciascun hash identificherà univocamente un utente. Nessuno di questi è elegante come la risposta migliore qui (e suggerirei di usare anche questo), ma sono più accurati.

Una soluzione semplice ma fastidiosa potrebbe essere quella di avere un layout tastiera su schermo di pulsanti html, dove gli utenti possono solo digitare il loro nome utente usando questi pulsanti, questo impedirà l'errore, mi rendo conto di quanto possa essere fastidioso questo essere fuori, ma dopo il primo accesso, è possibile utilizzare un cookie per ricordare il nome utente e non richiederlo di nuovo. Naturalmente sarà richiesto Javascript Ora è impossibile inviare la password in testo semplice per sbaglio. Spero che aiuti.

Ho un approccio diverso ... Che problema stai cercando di risolvere davvero?

1. Password errate? Cioè quando vedi una persona usa "password" (o una variante) vuoi essere in grado di risalire all'utente e correggerlo?

2. Password inviate in chiaro?

3. Oppure il problema con gli idioti che non possono digitare o leggere i moduli (o forse un'interfaccia utente progettata male)?

Ricorda sempre che ogni volta che "aggiungi" al sistema stai potenzialmente aggiungendo complessità e aggiungi definitivamente del codice - entrambi che aumentano la possibilità di aprire "buchi" di sicurezza nell'architettura generale da qualche parte (potrebbero essere nello stack, potrebbe essere via web, potrebbe essere sopra la rete ...). Quindi, nel risolvere uno qualsiasi dei 3 devi misurare se il valore di risolverli vale il rischio di ficcare un buco che non conosci: il diavolo che conosci è sempre meglio del diavolo che non conosci.

Ora a ciascuno.

La risoluzione delle password errate dovrebbe essere eseguita al momento dell'impostazione e modifica della password tramite le regole di convalida. E solo lì. Aggiungere un altro posto per farlo, significa solo rischiare che le regole di convalida siano confuse o non sincronizzate.

Password inviate in chiaro. Che importa? Concesso potrebbe "sentirsi" non sicuri, ma ricorda che questa è l'autenticazione delle parti e se hai solo 1 parte non è diverso dall'avere una parola in un dizionario. Forse, forse, se hai uno sniffer attivo, potresti dare loro qualche indizio, ma l'intrusione già in atto è il tuo vero problema, non qualche sporadico, casuale, fat-finger delle password nel campo del nome utente. Ora se hai inviato tutte le parti nel chiaro, grande problema.

Problema di idioti o cattiva progettazione dell'interfaccia utente. Mediazione degli utenti o dell'interfaccia utente. Semplice. Fornire assistenza attiva sull'interfaccia utente, fare in modo che i reparti seguano un corso di formazione o qualcosa del genere. Correzione facile che richiede modifiche codificate a basso rischio (o dovrebbe - fare attenzione però con l'aspetto dell'interfaccia utente).

Mentre ammiro molti dei suggerimenti qui, e molti di loro hanno idee meravigliose nel loro nucleo. Raccomando un BACIO, nessun approccio BS, ricordando sempre che se aggiungi ai tuoi sistemi rischi di aumentare la tua insicurezza.

Solo i miei 2 cent.

• consente solo di trasmettere hash md5 di nomi utente e password (o hash simili), in modo che qualsiasi cosa venga registrata nei file di log sembrerà sempre una lunghezza fissa di caratteri casuali, il che non renderà nessuno in grado di indovinare rapidamente che è un md5 di una password o di un nome utente.

Contro: per confrontare i nomi utente nel tuo database devi memorizzare due colonne, ad es. 'username' e 'md5 (username)' OPPURE devi eseguire l'hash dinamicamente ogni volta che stai interrogando il nome utente per il login.

• crea una voce di registro solo se il nome utente esiste nel database, altrimenti registra solo ip.

• consente all'utente di fare clic su Invio solo con il mouse, non con la tastiera o con la tastiera dopo 5 secondi dall'ultimo carattere immesso in entrambi i campi, che consentirà all'utente di guardare lo schermo e vedere il suo errore.

• fare alcune restrizioni per consentire nomi utente e password:

  1. le password devono contenere un carattere speciale come! @ # $% ^ & * ()
  I nomi utente
  2. NON devono contenere caratteri speciali

In questo modo, puoi fare javascript per identificare rapidamente se il nome utente o la password inseriti.

I dati biometrici sono abbastanza economici ora e funzionano almeno per l'80% delle volte. Trovo fantastico su TabletPC e ho voluto implementare le tastiere biometriche perché è più veloce (almeno per quell'80% delle volte).

Scommetto che questo non è stato un grosso problema con Win2000, WinXP, Win2003 e WinVista perché per impostazione predefinita, il campo del nome utente era già pieno dell'ultimo nome utente riuscito. Non è esattamente sicuro quale versione di ActiveDirectory o workstation sia stata modificata, ma l'impostazione predefinita è che il campo del nome utente sia vuoto, il che rende questo problema più diffuso.