Domanda:
Le password vengono inviate in chiaro a causa dell'errore degli utenti nel digitarle nel campo del nome utente
Lex
2013-03-05 22:09:55 UTC
view on stackexchange narkive permalink

Dopo aver esaminato i log generati da diversi SIEM (Splunk, HP Logger Trial e SIEM della piattaforma AlienVault) ho notato che per qualche motivo molti utenti tendono a commettere l'errore di digitare le proprie password nel campo del nome utente, sia nel campo Accesso al dominio del sistema operativo o all'interno delle applicazioni web. Immagino che quelle siano persone che non possono digitare senza guardare la tastiera e nel provare a farlo, facendolo velocemente, finiscono per digitare le loro password nel campo sbagliato. Ciò significa che la password viene inviata in testo normale ovunque nella rete e finisce per essere registrata nei log con un evento che dice qualcosa del genere:

  L'utente P @ $$ w0rd non esiste [...]  

Oppure

  Impossibile accedere a un account: P @ $$ w0rd [...]  

(dove P @ $$ w0rd è la password dell'utente effettivo)

Diventa abbastanza ovvio capire a chi appartengono le password: di solito l'evento precedente o quello successivo (non) riuscito sul lo stesso file di registro ti dirà un evento attivato dallo stesso utente.

Qualsiasi altro analista, guardando i log, potrebbe ottenere le credenziali di qualcun altro senza che il proprietario ne sia nemmeno a conoscenza; lo scenario peggiore è l'intercettazione di rete o la compromissione del file di registro.

Sto cercando una guida generale per aiutare a prevenire questo problema. Presumo che mascherare semplicemente il nome utente non sia fattibile e anche se lo fosse, questo probabilmente eliminerebbe gran parte dell'analisi dei log per non essere in grado di dire chi ha fatto cosa.

Nota: b > Esiste già un post su un problema simile, ma sto cercando di trovare un modo per evitarlo. Qual è il rischio se digito accidentalmente la mia password in un campo nome utente (accesso a Windows)?


Risposta accettata: vorrei poter selezionare alcune risposte dall'elenco. Sfortunatamente devo attenermi a uno solo nel forum, ma in pratica posso combinarli. Grazie mille per tutte le risposte; Vedo che non esiste un'unica soluzione. Poiché sono d'accordo sul fatto che l'aggiunta di "cose" aggiunga complessità che aumenta la probabilità di falle nella sicurezza, sono d'accordo con la maggior parte degli elettori sul fatto che @AJHenderson ha la risposta più elegante e semplice come primo approccio. Sicuramente SSL e una semplice verifica del codice sul server o anche lato client. Dato che sto cercando di mitigare non gli utenti malintenzionati, ma quelli distratti, questo andrà bene. Una volta che questo è in atto, possiamo iniziare a cercare di espandere l'implementazione a utenti malintenzionati, se appropriato. Grazie mille ancora per il contributo di tutti.

Hash sia nome utente che password e invia attraverso. Ovviamente la creazione dell'account deve avvenire su HTTPS. Non è necessario che siano necessari ulteriori accessi.
@SparKot ॐ - il problema è che se si esegue l'hash del nome utente, senza un sale comune, è estremamente difficile identificare l'utente. Con un sale comune per il nome utente, diventa possibile eseguire un attacco della tabella arcobaleno contro i registri per trovare password errate.
Rainbow table come analista siem con registri delle app e altri che contano più di 5000+ eps suona molto inopportuno. Esistono soluzioni siem come Q1 che avvisano su una regex definita per verificare i tipi di nome utente.
@Lex Sono confuso qual è il rischio che qualcuno fiuti la password in questo modo dal filo? Quanta minaccia implica? Se ho qualcosa come sslstrip batte tutta la sicurezza sul filo.
Accedi solo se il nome utente esiste nel db?
@asadz la minaccia mi sembra piuttosto grande, dal momento che la password potrebbe essere trasmessa in chiaro dal nome utente archiviato come se fosse il nome utente. La probabilità potrebbe essere minima, tuttavia la probabilità di frode interna da parte di qualcuno che abusa dei privilegi di visualizzazione del registro della password memorizzata in chiaro è quella che mi spaventa di più.
@Lex ma questo sarebbe un altro rischio che tutti insieme venissero salvati in chiaro sulla macchina, mi riferivo al rischio di essere fiutato dal filo. L'attaccante deve essere molto fortunato in quel caso. A seconda della risposta del sistema (se richiede un token / password una tantum) o della pre-autenticazione in qualche modo, la possibilità di un effettivo compromesso è molto inferiore.
@asadz Sono d'accordo con te al 100%
@CodesInChaos è un'idea interessante e sono sicuro che sia possibile implementare un filtro regex per questo.
Anche quelli di noi che sanno digitare senza guardare la tastiera possono commettere questo errore. Di solito non abbiamo nemmeno bisogno di guardare lo schermo e se uno è leggermente distratto, un errore del genere è facile da fare. Questo è il vantaggio dell'edizione Windows XP Home e dell'interfaccia successiva in cui è un menu di utenti tra cui scegliere. Ovviamente non è utile con più di una manciata di utenti.
Questo mi succedeva sempre, per il seguente motivo: in genere, quando sblocco il mio computer, si ricorda che ero l'ultimo utente e solo la password deve essere inserita. Io spesso "[ctrl] - [alt] - [del]" e inserisco la mia password prima che l'alimentazione venga ripristinata al mio monitor. Tuttavia, se il mio ultimo accesso è stato tramite desktop remoto, il nome utente viene cancellato. Seguendo la mia normale routine in questo scenario, la password viene inserita come nome utente.
Digitare la mia password in qualcosa di diverso da una casella di immissione della password è probabilmente la causa principale delle modifiche della password per me. Probabilmente dovrei commettere questo errore più spesso!
Ho due macchine e una tastiera. Uso del mouse senza bordi A volte digito la mia password ogni volta che PENSO che il cursore sia focalizzato. Non sempre la casella che necessita del login
Improvvisamente sento il bisogno di cambiare varie password ... Inoltre, quando l'ho fatto in passato, spesso quello che succede è che sto digitando molto velocemente e per sbaglio perdo il tasto "tab" per passare al campo successivo. In altre parole ... Un account non è riuscito ad accedere: MikeSP @ $$ W0RD
Ho notato un bug davvero fastidioso in cui in una pagina web passerò al campo della password e inizierò a digitare prima che la pagina finisca di caricarsi, quindi quando la pagina finisce (a metà strada digitando la mia password) strapperà il focus dal campo della password e di nuovo al valore predefinito (di solito il campo del nome utente). Vorrei che tutti si assicurassero che il loro prodotto / sito web non lo facesse.
Se possibile, puoi aggiungere un nuovo campo, ad esempio reinserire la password e aggiungere una convalida lato client?
@Lex "... per qualche motivo ..." Sto solo speculando sul motivo: c'è javascript nella pagina che mette l'accento sulla casella del nome utente dopo il caricamento della pagina? Il mio sito web bancario fa questo e mi sono ritrovato a digitare il mio pw nel campo del nome utente a causa del carico asincrono. (ad esempio, ho digitato il mio nome utente e durante la digitazione - o subito prima di digitare - il mio pw, la pagina si caricava completamente, impostavo il focus su nome utente e il mio pw andava nel campo nome utente).
@Sufyan - sì, anche questo sarebbe efficace, ma sarebbe un successo di usabilità in quanto richiede un lavoro extra da parte dell'utente che generalmente lo renderà scarsamente ricevuto. Non sto dicendo che non potrebbe essere la scelta giusta in alcune situazioni, ma non sarebbe popolare.
-> L'utente P @ $$ w0rd non ** esce ** è un ovvio errore di battitura.
[Mi scuso se qualcun altro ha già fatto questo commento] Questo genere di cose accade molto di più ora che così tante persone usano cose come KeePass per digitare automaticamente le proprie credenziali. È molto facile avere il focus nel campo sbagliato e quindi il nome, la scheda, la password, la sequenza di immissione digitati automaticamente riempiono i campi sbagliati.
@ray023 Non posso dirtelo, temo. Tuttavia, ciò accade anche alle persone che commettono i propri errori durante l'accesso a Windows.
Recentemente ho avuto qualcosa di simile quando un utente ha inserito "Authorization Basic " nell'URL stesso (parametro query) invece che nell'intestazione HTTP ... mi dispiace per lui ma la sua richiesta è andata al file "NCSA-logs" enon possiamo semplicemente impedire di registrarlo poiché non analizziamo il messaggio di log prima di registrarlo.
Diciassette risposte:
#1
+365
AJ Henderson
2013-03-05 23:33:26 UTC
view on stackexchange narkive permalink

Un pensiero è di non consentire l'invio di moduli se non è presente un valore nella casella della password. In genere, se hanno inserito 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 fintanto che il trasporto utilizzato è sicuro e l'input non viene registrato fino a dopo aver superato un controllo sul campo della password non vuoto.

Semplice, ma elegante. Vorrei potergli dare un +5.
Infatti. Se proviamo a combinare questo con un filtro di livello base come suggerito da @CodesInChaos. +1
Un controllo javascript bypassato invierebbe il nome utente attraverso il cavo che è dove si applica il rischio. Sarebbe scelto da qualcosa di simile a WireShark e se il suo SSL sarebbe ancora, ad esempio, sslstrip http://www. Thoughtcrime.org/software/sslstrip/
peccato che non possiamo convincere MS a implementarlo per la finestra di dialogo di accesso di Windows.
@asadz: sì, non è una prevenzione contro un utente malintenzionato che fa qualcosa, la domanda era solo su cosa si poteva fare per impedire che le password finissero nei file di registro dagli utenti che commettevano errori.
Questo può essere garantito senza i controlli JavaScript nei browser moderni? Esiste un tipo di elemento richiesto per il modulo prima di HTML5 (http://john.foliot.ca/required-inputs/)
@DanNeely Ma la finestra di dialogo di accesso di Windows può avere una password di lunghezza zero. Quindi questa soluzione non può essere implementata lì, vero?
@EricG: Dato che la preoccupazione * principale * dell'OP è con i log del server piuttosto che con lo sniffing della rete, la logica potrebbe essere duplicata sul lato server prima di includere il nome utente nel messaggio di log.
@ruakh: Questo è un buon punto, ma non è quello che dice la risposta, dice impedire l'invio del modulo, non impedire la registrazione, che è suggerito in un paio di altre risposte.
@EricG: Sì, sono d'accordo. Gran parte dello scopo dei commenti è aiutare a migliorare le risposte, quindi stavo suggerendo qualcosa che pensavo potesse aiutare ad affrontare il tuo problema con questa risposta.
@AnuragKalia quindi abilitalo solo nel caso in cui sia in atto una policy per la password.
Contributo popolare di @AJ Henderson :).
D'accordo: bella vittoria facile e veloce per il lato client.
Qualcuno ha un modo concreto per farlo o ci affidiamo solo a JavaScript? In tal caso, dovremmo espandere questa risposta con alcuni dettagli?
@EricG - Ho aggiornato la risposta per riflettere che questo potrebbe essere fatto anche lato server. Sebbene la forma sia una parola chiave per un post HTML, non è mai stata un'implicazione intenzionale della mia risposta. L'idea è semplicemente che non si elabora un tentativo di accesso fino a quando il campo della password non ha un valore. Questo potrebbe essere sul server o sul client.
@Iszi * Puoi * dargli un +5 facendo cadere una taglia.
@AJHenderson: Suppongo che i registri del server web o del traffico di rete possano contenere la password. È possibile interrompere l'elaborazione prima che vengano formati i registri a livello di applicazione. Avresti bisogno di filtri sulla tua registrazione web / rete.
@EricG: se stai registrando i dati dei post di ogni invio del forum, ci sarà un sacco di registrazione. Suppongo che dovresti comunque stare attento a come imposti le cose, ma penso che potresti probabilmente aggirare il fatto che venga registrato fintanto che non prova effettivamente l'autenticazione. Certo, potrebbe non funzionare in tutti i sistemi.
Bella soluzione, grazie per questo suggerimento! Tutte le finestre di dialogo di accesso dovrebbero implementarlo. Inizierò implementandolo in una delle mie applicazioni.
#2
+39
fixulate
2013-03-05 22:13:39 UTC
view on stackexchange narkive permalink

Supponendo che la tua applicazione backend e SIEM debbano visualizzare i tentativi di accesso non riusciti a varie applicazioni (e quindi mostrare il messaggio di errore "L'utente P @ $$ w0rd non è valido"), non sarà banale fermarlo.

Tuttavia, assicurarsi che tutte le applicazioni che inviano dati sensibili, inclusi nomi utente e password, implementino HTTPS (HTTP crittografato utilizzando SSL) è un buon modo per garantire che i dispositivi di rete e chiunque sia in rete non possano ottenere la password erroneamente inserito nella casella del nome utente!

Infatti. questo risolverebbe la metà dei miei problemi / preoccupazioni. +1. Grazie mille.
Immagino che ssl sia una soluzione alternativa, non una correzione del codice. I problemi dovrebbero essere risolti al meglio alla fonte.
@asadz: il fatto che l'applicazione mostri il nome utente quando viene inserito in modo errato non è un bug dell'applicazione, è una funzionalità prevista e non richiede una correzione imo.
@devcity2012 Una funzionalità voluta forse ma mal pensata; c'è una parte dell'analisi dei requisiti nell'ingegneria del software; qui è dove queste cose dovrebbero essere ricercate preferibilmente usando il diagramma di sequenza; come mai non c'è controllo per un modulo prima dell'invio? Validazione input nulla?
Se il modulo accetta un nome utente e una password ed entrambi sono presenti e quindi il backend è configurato per visualizzare il nome utente, non è un errore dell'applicazione se l'utente inserisce per errore la propria password nel campo di testo del nome utente.
Lo parlo come un problema solo nel senso in cui una richiesta verrebbe presentata solo in base al campo del nome utente?
Sì certo, allora si può fermare sì. :)
#3
+22
Nathan Goings
2013-03-06 07:13:02 UTC
view on stackexchange narkive permalink

Posso solo identificare tre problemi con ciò di cui stai discutendo.

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

Secondo me, questo è abbastanza semplice da risolvere.

  1. Accetta l'errore dell'utente, a malincuore.
  2. Non registrare nomi utente non validi, ma registrare tentativi falliti e IP.
  3. Non inviare nomi utente in chiaro. Utilizza una tecnologia come HTTPS o utilizza javascript per codificare il testo normale (ad es. ROT13).

Registro di esempio di un accesso non riuscito e quindi un nuovo tentativo riuscito.

  [00:00:00] Un account non è riuscito ad accedere da 192.168.1.100 [00:21:00] Accesso riuscito "root" da 192.168.1.100  

Rileggendo altre risposte, vorrei includere questo.

  • Convalida tutti i campi prima dell'invio.
  • Considera l'idea di suddividere il modulo tra più pagine come Eric G menzionato.
Non sono sicuro di cosa intendi esattamente con "crea il tuo in javascript" ma sono abbastanza sicuro che sia una cattiva idea.
-1 non rotola mai il tuo https in javascript. Se non è questo ciò che intendevi, chiarisci.
@makerofthings7 ho chiarito. Non ho mai detto roll https in javascript, ho detto OR javascript (chiarito con crittografia). Sebbene non sia il modo più semplice da implementare * correttamente *, ci sono risorse per quel tipo di soluzione. È una risposta valida e non vedo perché valga un punto negativo.
Javascript con codice crittografico fornito dal server (che è quello che sembri descrivere) è raramente una buona idea. Il server può modificare quel codice JS ed esporre le chiavi private locali. Un altro vettore è XSS / CSRF. È un progetto di sicurezza rischioso. HTTPS dovrebbe essere un minimo. Fammi sapere se stai pensando a qualche altra distribuzione, come un'applicazione HTML / SPA inclusa in PhoneGap o qualcosa di simile.
@makerofthings7, Il mio processo di pensiero non era per l'uomo nel mezzo. Questa è una lattina di vermi. Immaginavo di origliare. Uno dei sistemi su cui ho lavorato codificava tutti i dati del modulo con javascript (con una chiave casuale) in modo che i colleghi non potessero curiosare a vicenda.
#4
+22
goodguys_activate
2013-03-05 23:43:00 UTC
view on stackexchange narkive permalink

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

Attenzione: anche se si utilizza Javascript, non si tratta dei dati della password archiviati sul disco in testo normale.

Una soluzione migliore è preelaborare i log prima che gli analisti li vedano e redigere le informazioni nei log.

Puoi applicare questo filtro riga per riga se inserisci righe nella whitelist o nella blacklist Linee. Ad esempio:

Puoi inserire nella whitelist i nomi utente quando compaiono in un file di log che

  • hanno un modello ([az] + numero) o ([az] + punto + [az])
  • includere un nome di dominio seguito da una barra "\" per ambienti AD
  • apparire più volte
  • Può essere confrontato con una directory LDAP di nomi utente noti prima che gli analisti lo vedano

Puoi anche identificare e inserire nella lista nera le password:

  • La politica della password spesso segue uno schema (un simbolo, maiuscole / minuscole, caratteri x ...)

Puoi usare questa conoscenza per costruire un pulitore di dati di log personalizzato per proteggere le informazioni che don Voglio che gli analisti vedano.

Allora, che aspetto ha una riga filtrata?

Puoi semplicemente redigere nomi utente discutibili eseguendo l'hashing, assegnando loro un ID umano e memorizzandoli in una posizione sicura:

  eb574b236133e60c989c6f472f07827b Redact1 7e67b89a695bfbffc05b7ed2c38f927f Redact2 ..etc  

Gli analisti possono vedere se una determinata voce si ripete più e più volte se in frequenza.

L'esatto metodo di hashing (o metodo di crittografia) che scegli è soggetto a rischi poiché questo "database hash" conterrà informazioni di alto valore. E il seeding (per sua natura) impedirà l'analisi della frequenza che può essere o meno utile per te.

+1 è una buona idea presumere sempre che i log contengano informazioni sensibili a meno che non vengano esplicitamente oscurati o fino a prova contraria.
#5
+14
Eric G
2013-03-06 01:49:18 UTC
view on stackexchange narkive permalink

Una soluzione che ho visto implementare da alcune banche, almeno nelle app web, è avere un login su due pagine.

  1. Nella prima pagina accetta solo il nome utente
  2. Nella pagina successiva del processo richiedi la password ed esegui solo l'eco del nome utente in modo che non sia un campo modificabile

Pertanto l'unico input nella seconda pagina dovrebbe essere la password. Poiché l'utente sa che deve cancellare la prima pagina con un nome utente, sa che deve cancellare quel cancello, quindi l'unica opzione nella seconda pagina è la password.

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


Inoltre, considerando la tua registrazione: forse puoi cambiare la tua registrazione 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 di accedere", quindi "L'utente con ID" 2342342 "ha fornito con successo una password ".

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

Questi sarebbero i log a livello di app. I registri del server Web possono includere parametri di query, quindi potrebbe essere un po 'più difficile da risolvere o forse è possibile inserire un tipo di filtro proxy tra l'azione e quando il registro viene scritto per oscurare il contenuto del registro in base a determinate regole. Questo sarebbe specifico della piattaforma, ma sembra che potrebbe essere possibile su Apache.

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

autenticazione seriale? Forse
I moduli in due passaggi sono in realtà l'unico posto in cui è più probabile che inciampi e inserisca la mia password nel campo del nome utente sulla prima pagina!
Sarei interessato a saperne di più sul caso UX, hai qualche motivo per cui pensi che ciò accada? L'accesso al sito memorizza il tuo nome utente durante le visite ripetute o no? Immagino che sarebbe d'aiuto (ma potrebbe far male) dal momento che non avresti nemmeno una casella da digitare se precompila il tuo nome utente. Fammi sapere qualche dettaglio in più e vedrò se posso aggiungere alcune informazioni aggiuntive alla mia risposta.
Questo mi rende molto meno frustrato dal fatto che una delle mie banche lo faccia, grazie per questa risposta (hah).
#6
+4
Abhijit
2013-03-06 01:23:39 UTC
view on stackexchange narkive permalink

In generale, tutto il codice client è abbastanza intelligente da gestire gli errori di base

  1. ID utente e / o password mancanti
  2. Password non conforme alle linee guida
  3. ol>

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

      L'utente P @ $$ w0rd non esce [...] Un account non è riuscito ad accedere: P @ $$ w0rd [...]  

    Nessuna delle convalide client ha funzionato e il sistema ha finito per inviare la password non crittografata sulla rete. Allora cosa c'era nel campo della password? Sicuramente non vuoto poiché la convalida del client fallirebbe. Deve essere qualcosa di diverso dalla password

    Quindi rendila un'autenticazione in due passaggi

    1. Primo passaggio, invia tutti i dettagli crittografati inclusa la password al server. Verifica se il campo Password è vuoto.
    2. Primo passaggio, verifica se la password corrisponde alle linee guida altrimenti Errore fuori.
    3. Primo passaggio, quindi controlla se la password è presente nel tuo DB. If not 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
    6. ol >

      L'essenza di questo processo è

      1. Ridurre al minimo il rischio. Nota, non puoi eliminare il rischio di Zero
      2. Non fidarti del cliente.

      Infine, fai esaminare la tua interfaccia da un esperto di UX. Potrebbe essere che la tua interfaccia abbia qualche difetto che fa sì che gli utenti inseriscano la password nel campo ID.

Ottimo suggerimento. Penso che la maggior parte delle risposte qui finora fornisca un buon riassunto e tutto ha molto senso. +1
#7
+4
Kevin Reid
2013-03-06 10:06:44 UTC
view on stackexchange narkive permalink

Da quello che descrivi della tua architettura, questo non è fattibile, ma secondo me la soluzione corretta è: non inviare il nome utente in chiaro e non registrare i nomi utente dei tentativi di accesso falliti. L ' unico posto in cui devono essere inseriti nome utente e password è il sottosistema che controlla la password; fino a quando ciò non si verifica, il nome utente è dati arbitrari non autenticati : chiunque abbia accesso al modulo di accesso, che in un'applicazione web è l'intera Internet, può digitare tutto ciò che vuole con la frequenza che vuole - e quindi ti dice molto poco di interesse. (A meno che il tuo modulo di accesso non sia esposto a Internet.)

questo probabilmente eliminerebbe gran parte dell'analisi del registro per non essere in grado di dire chi ha fatto cosa ....?

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

-1
#8
+4
nalply
2013-03-06 17:24:05 UTC
view on stackexchange narkive permalink

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

Lascia che un altro provider di identità faccia il duro lavoro di mantenere le credenziali protette. Fai la stessa cosa di StackOverflow: consenti l'autenticazione con OpenID, Gmail, ecc.

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

#9
+3
dr jimbob
2013-03-06 04:29:30 UTC
view on stackexchange narkive permalink

Il javascript lato client sembra ragionevole.

Il campo Verifica password non è vuoto, prima dell'invio. Verifica che il nome utente sia in una forma valida. Particolarmente elegante è qualcosa in cui il nome utente deve essere un indirizzo e-mail. È inoltre possibile impedire che la password al meccanismo di impostazione / modifica della password sia sotto forma di indirizzo e-mail. Quindi controlla semplicemente che il nome utente sia nella forma di un indirizzo email valido prima di inviare il modulo. Questo potrebbe essere fatto in modo simile con diciamo caratteri speciali o numeri. (Ad esempio, i numeri / caratteri speciali sono richiesti nelle password ma non sono consentiti dai nomi utente).

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

#10
+2
Daniel Pryden
2013-03-06 09:53:14 UTC
view on stackexchange narkive permalink

Mi piace l'approccio che la mia azienda attuale adotta a questo problema: se digiti la password nella casella sbagliata, un sistema automatizzato fa scadere immediatamente la tua password. Pertanto l'utente deve cambiare la propria password e la password che si trova nel registro ora non è più vulnerabile.

Ovviamente, questo non è ancora l'ideale se l'utente sta ancora utilizzando quella password per un altro sistema, ma si spera che essere costretti a cambiare la propria password renderà un utente più consapevole dei possibili rischi per la sicurezza.

Come funziona? Controlla il `nome utente` con la` password` memorizzata nel database, se corrispondono, forza il ripristino? Questo è basato sul web o anche a livello di Windows / LDAP? In tal caso, si tratta di un prodotto personalizzato o pronto all'uso?
@EricG: È un sistema personalizzato e non l'ho costruito, quindi non so davvero come sia stato implementato. Detto questo, credo che funzioni eseguendo l'hashing del nome utente e controllando gli hash rispetto agli hash delle password. La mia comprensione è che mantengono un database da qualche parte di "password trovate in circostanze sospette" e fanno scadere tutte le password attive che corrispondono a tale elenco.
Penso che ti sei perso la parte in cui chiedeva come facevano a sapere che la password era stata inserita nel campo del nome.
@jcolebrand: Scusate, pensavo di aver spiegato che: hash tutto ciò che viene inserito nel campo del nome utente e controlla l'hash contro il database delle password. Facoltativamente, usa qualcosa come un filtro Bloom se hai un database di password molto grande e vuoi controllare rapidamente. Non ho idea se questo sia ciò che effettivamente fanno, però: forse c'è un modo ancora migliore.
Potrebbe effettivamente essere una cosa valida da fare. Quindi il problema è che posso inserire 1234567 o password1 ecc. E invalidare un sacco di password. Se penso di conoscere la password dei miei amici, ecc.
Sono con EricG. Non capisco come implementarlo effettivamente in modo sicuro. Se il database delle password sta memorizzando la password utilizzando un salt (e utilizzando un hash della password lento come bcrypt), non è facile verificare se un nome utente errato è effettivamente la password di qualcuno e, in tal caso, trova di chi era: il meglio che puoi fare è una ricerca esaustiva su tutti gli utenti nel database, che non è scalabile. Se il database delle password non utilizza un salt (o non utilizza un hash lento della password), hai problemi più seri: è un no-no definitivo.
#11
+2
Izac Mac
2013-03-06 21:18:47 UTC
view on stackexchange narkive permalink

Per lo più la risposta PIÙ FACILE è la risposta giusta. Ora notiamo che ogni indirizzo email ha un segno "@" appena prima del nome di dominio. Rendere "@" una chiave NON ACCETTABILE nella password rende la soluzione abbastanza ovvia. Se il nome utente NON ha @ e TUTTI GLI USERNAME sono indirizzi e-mail, registra solo quelli che contengono almeno @.

Ora se il nome utente NON ha "@", probabilmente alcuni utenti potrebbero arrabbiarsi ma questa è una buona soluzione. Cioè avere UN SOLO carattere speciale che precede una password. Proprio come TUTTI I NOMI UTENTE 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 inserisce una password, gli fai sapere che deve digitarla.

La terza soluzione è quella CODIFICA COLORE. Rendi il campo nome utente giallo e il campo password ROSSO. Il rosso normalmente cattura la tua attenzione perché è usato per cose sensibili. Quindi, anche se stanno guardando la tastiera, IMPARERANNO MOLTO RAPIDAMENTE che le password sono rosse Quindi, in pratica, il campo di testo E L'etichetta della password è preferibilmente rossa in una casella separata e l'etichetta del nome utente e il campo di testo TUTTO GIALLO.

L'utilizzo di indirizzi e-mail come nomi utente è tutt'altro che universale per le app pubbliche ed è raro nelle app interne. È improbabile che la codifica a colori sia d'aiuto: la ragione normale per utilizzare il campo sbagliato è la disattenzione su quale campo è focalizzato (specialmente quando il campo del nome utente è di solito precompilato ma per qualche motivo non è in un'istanza).
#12
  0
l--''''''---------''''''''''''
2013-03-06 02:01:05 UTC
view on stackexchange narkive permalink

Perché non rispondi semplicemente con questo?

  Quel nome utente non esiste  
Probabilmente non dovresti farlo, o addirittura impiegare una quantità di tempo diversa nella risposta. Risposte come questa e talvolta la differenza nella quantità di tempo necessaria per l'elaborazione può essere utilizzata in modo improprio forniscono un elenco di nomi utente validi, che potrebbero anche essere utilizzati per motivi diversi dal semplice tentativo di accedere al sito / servizio stesso (ad esempio potrebbero prova a inviare un'e-mail allo stesso nome utente in Gmail, ecc.).
@GaryS.Weaver: <- Sì. ad esempio, crei un test A / B nel tuo brute forcer e ogni volta che ottieni le diverse condizioni sai di aver identificato un nome utente valido.
@GaryS.Weaver non esiste una soluzione infallibile, ma non pensi che sia un po 'eccessivo? non gestisce americanexpress.com
@ Артём-Царионов sta a te, a lui e a tutti gli altri implementare la sicurezza come meglio credono.
Il problema nella domanda è che il nome utente finisce nei file di registro che fanno una registrazione permanente del nome utente in testo normale. Se il server fosse mai stato compromesso o un amministratore non fosse onesto, potrebbe accedere all'account dell'utente senza alcun record nel sistema. Il file di registro deve ancora sapere quali nomi utente vengono provati, quindi la soluzione dovrebbe in qualche modo impedire che una password venga memorizzata in un registro se viene inserita nel campo del nome utente.
@AJHenderson grazie! All'inizio non ho capito
#13
  0
A. Wilson
2013-03-06 06:48:39 UTC
view on stackexchange narkive permalink

Quanto controllo hai sulla gestione di questa operazione da parte del server ricevente? Sembra che la soluzione proposta da un utente sopra, per hash sia il nome utente che la password, sarebbe realizzabile in un paio di modi:

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

Metodo 2 (non richiede JavaScript): Ricevi il nome utente in chiaro come al solito, ma convertilo in un hash come nel metodo 1 una volta ricevuto sul server. Quando il tentativo fallisce, registra l'hash, non il nome utente. I log saranno comunque utili (leggermente meno utili se ispezionati in modo accorto), poiché ogni hash identificherà ancora in modo univoco un utente. Nessuno di questi è elegante come la risposta migliore qui (e suggerirei di usarlo anche), ma sono più completi.

#14
  0
sharp12345
2013-03-06 08:52:51 UTC
view on stackexchange narkive permalink
  • 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 indovina rapidamente che si tratta di un md5 di una password o di un nome utente.

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


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

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

  • applica alcune limitazioni ai nomi utente e alle password consentiti:

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

In questo modo, puoi usare javascript per identificare rapidamente se il nome utente inserito è o password.

#15
  0
louis_coetzee
2013-03-06 15:54:52 UTC
view on stackexchange narkive permalink

Una soluzione semplice ma fastidiosa potrebbe essere quella di avere un layout di tastiera su schermo di pulsanti html, dove gli utenti possono solo digitare il proprio nome utente usando questi pulsanti, questo eviterà che l'errore venga commesso, mi rendo conto di quanto possa diventare fastidioso ma dopo il primo login, potresti usare un cookie per ricordare il nome utente e non richiederlo di nuovo. Ovviamente sarà richiesto Javascript. Ora è impossibile inviare la password in testo normale per errore. Spero che aiuti.

vero, ma che dire delle persone che accedono al proprio dominio Windows da un laptop? Raccogliamo anche questi registri.
#16
  0
Tek Tengu
2013-03-06 17:55:00 UTC
view on stackexchange narkive permalink

La mia opinione è diversa ... Quale problema stai cercando di risolvere veramente?

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

  2. Le password vengono inviate in chiaro?

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

Ricorda sempre che ogni volta che "aggiungi" al sistema stai potenzialmente aggiungendo complessità e stai sicuramente aggiungendo codice - entrambi aumentano la possibilità di aprire "buchi" di sicurezza nella tua architettura complessiva da qualche parte (potrebbero essere nello stack, potrebbero essere via web, potrebbe essere in rete ...). Quindi, nel risolvere uno qualsiasi dei 3, devi misurare se il valore di risolverli vale il rischio di fare 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 durante la configurazione e la modifica della password tramite le regole di convalida. E solo lì. Aggiungere un altro posto in cui farlo, significa solo che rischi di confondere le regole di convalida o di non essere sincronizzate.

Le password vengono inviate in chiaro. Che importa? Concesso potrebbe "sembrare" pericoloso, ma ricorda che questa è un'autenticazione in parte e se hai solo 1 parte non è diverso dall'avere una parola in un dizionario. Forse, solo forse se hai uno sniffer attivo potrebbe dare loro qualche indizio, ma allora l'intrusione già in atto è il tuo vero problema, non qualche occasionale, casuale, grasso diteggiatura di password nel campo del nome utente. Ora, se tutte le parti vengono inviate nel chiaro, grosso problema.

Problema di idioti o cattivo design dell'interfaccia utente. Ripeti la mediazione di utenti o interfaccia utente. Semplice. Fornisci aiuto attivo sull'interfaccia utente, chiedi ai dipartimenti di seguire un po 'di formazione o qualcosa del genere. Soluzione semplice che richiede modifiche alla codifica limitate e a basso rischio (o che dovresti comunque prestare attenzione all'aspetto dell'interfaccia utente).

Anche se ammiro molti dei suggerimenti qui presentati, e molti di loro hanno idee meravigliose al centro. Consiglio un approccio KISS, no BS, ricordando sempre che se aggiungi ai tuoi sistemi rischi di aumentare la tua insicurezza.

Solo i miei 2 centesimi.

#17
  0
rjt
2014-07-31 14:21:09 UTC
view on stackexchange narkive permalink

La biometria adesso è piuttosto economica e funziona almeno l'80% delle volte. Lo trovo fantastico su TabletPC e ho voluto distribuire tastiere biometriche perché è più veloce (almeno per l'80% delle volte).

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



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...