C'è qualche motivo per non mostrare agli utenti le password immesse in modo errato dopo un login riuscito?

Il problema principale è che le password errate devono essere archiviate in un modo che consenta loro di essere visualizzate in seguito agli utenti. Che, come ha sottolineato il tuo dev, significa che non possono essere prima crittografati con hash. Il risultato è che li memorizzi come testo normale (non valido) o crittografato (meglio ma non normalmente consigliato).

Il più grande rischio è se questo database di password non valide diventa accessibile agli aggressori. O compromettono il server, eseguono l'iniezione SQL o lo recuperano in altro modo. Piuttosto che infrangere le password primarie, che si spera siano strongmente hash e quindi obiettivi più difficili, potrebbero decidere di compromettere gli account usando le informazioni nella cronologia delle password non valide. O accedono facilmente alle password in chiaro, oppure tentano di trovare la chiave di crittografia che consente loro di decifrare di nuovo le password in chiaro.

Una fonte comune di errori di accesso è un errore di battitura durante la procedura di immissione della password. Quindi la mia password è Muffins16 ma inserisco mUFFINS16 perché il mio blocco maiuscolo è attivo. O Muffins166 perché ho colpito la stessa chiave due volte. O Muffina16 perché il mio dito ha colpito la chiave sbagliata. Come puoi vedere queste variazioni sono abbastanza vicine all'originale che gli autori di attacchi possono probabilmente determinare la password valida da password non valide provando alcune piccole modifiche o confrontando password errate con parole o nomi di dizionario probabili.

Questo problema è aggravato dal fatto che molte persone utilizzano le scelte di password simili a questi formati e non stringhe casuali. È più difficile per un utente malintenzionato identificare l'errore di battitura se la tua password non valida è V8Az $ p4 / fA, anche se è ancora più facile provare varianti di questo, quindi indovinarlo senza alcuna informazione.

Un altro rischio è che gli utenti non ricordino quale delle loro password hanno usato su questo sito in modo che provino quelli comuni. Ora questo sito è in qualche modo un obiettivo più grande perché un utente malintenzionato potrebbe non solo compromettere l'account di un utente lì, ma anche su altri siti con l'utile elenco di password "non valide".

È possibile attenuare alcuni di questi rischi cancellando la memoria delle password non valide immediatamente dopo la visualizzazione dopo un accesso valido. Ciò dovrebbe limitare la finestra di opportunità per un utente malintenzionato di accedere e trarre vantaggio dai dati.

La domanda che dovresti probabilmente chiedere al tuo cliente è come prevedono che gli utenti trarranno vantaggio dalla visualizzazione delle password non valide. È così che gli utenti possono identificare come hanno digitato in modo errato la loro password? Gli errori di battitura non sono intenzionali, quindi non è probabile che mostrare loro l'errore migliorerà i tentativi di accesso futuri. Quindi gli utenti possono identificare un utente malintenzionato che cerca di indovinare le proprie password? Commenti simili possono essere forniti elencando data, ora, IP / geolocalizzazione o altre informazioni per tentativi non validi senza la password tentata. Quindi gli utenti sanno che si sono rovinati durante l'immissione della password e non incolpano il sistema di login del sito? Questo sembra l'unico con merito e non sono sicuro che fornisca un valore sufficiente per giustificare il rischio.

La mia ipotesi è che una volta capito meglio cosa stanno cercando di ottenere con questa funzione, probabilmente potresti suggerire alternative più sicure.

tldr; questo è anche peggio che non tagliare le password e archiviarle come testo normale.

Sono d'accordo con le preoccupazioni del tuo lead dev. Per mostrare i passati tentativi di password errate, è necessario memorizzarli in modo reversibile, il che significa che non possono essere sottoposti a hash. Se qualcuno avesse compromesso il sistema, avrebbe quindi avuto accesso a tutti i tentativi sbagliati e probabilmente avrebbe potuto ricostruire le vere password per alcuni utenti. Ad esempio, se riesci a vedere alcuni dei miei tentativi sbagliati sono stati:

correct horrse battery staple
correct horse batttery staple

Sarebbe abbastanza facile capire la mia password attuale.

Sono inoltre d'accordo con la risposta di drewbenn : se inserisco il mio nome utente erroneamente ma con la mia password corretta, e il nome utente errato sembra essere il nome utente di qualcun altro, ora che l'utente può vedere la mia vera password.

Una volta ho provato ad accedere a un sistema usando la mia password ma il nome utente del mio collega.

Poi ci sono tutte le volte in cui ho usato la password sbagliata quando provo ad accedere ad un account condiviso.

E so che molti amministratori hanno accesso all'account del loro capo in modo che possano fare le cose. Sarei piuttosto scioccato se i loro capi non avessero mai inserito la password sbagliata, quindi sono stati distratti da un visitatore prima di accedere correttamente per cancellare l'errore.

Inoltre tutti gli errori di battitura quando qualcuno mi sta in piedi mentre sto effettuando l'accesso.

E in tutti questi casi, a volte ho inserito la mia password di Gmail o Lastpass nel prompt della password sul posto di lavoro, e viceversa.

E l'ora in cui ho cercato la mia password su Google perché non stavo guardando lo schermo e pensavo che fosse bloccato. Non che questo abbia qualcosa a che fare con la tua proposta, ma mi piace condividere quell'aneddoto perché ricorda alla gente che chiunque può commettere errori e digitare la cosa sbagliata a volte.

L'unica cosa che fa questa caratteristica di hUnt3r2 è trasformare piccoli errori (inserendo la password sbagliata o digitazione errata) in esposizioni accidentali a un pubblico più ampio.

Perdita di reputazione

Mettere in atto un tale meccanismo comporterebbe una perdita reputazionale immediata, considerando che ci sono stati casi di alto profilo in cui tentativi di accesso falliti sono stati utilizzati per attaccare altri siti. Ecco un esempio:

Mark (Zuckerberg) used his site, TheFacebook.com, to look up members of the site who identified themselves as members of the Crimson. Then he examined a log of failed logins to see if any of the Crimson members had ever entered an incorrect password into TheFacebook.com. If the cases in which they had entered failed logins, Mark tried to use them to access the Crimson members' Harvard email accounts. He successfully accessed two of them.

In other words, Mark appears to have used private login data from TheFacebook to hack into the separate email accounts of some TheFacebook users.

Fonte: Come Mark Zuckerberg ha hackerato nell'Harvard Crimson

Un'alternativa

Se il tuo cliente è deciso a mostrare tentativi di accesso non riusciti al prossimo accesso di successo, come una sorta di misura di benessere, posso suggerire un'alternativa? Invece di visualizzare le password non riuscite, visualizzare l'indirizzo IP e le informazioni di geolocalizzazione del browser che ha inviato la password errata. Dovrebbe essere abbastanza facile da fare, non causerebbe un problema di sicurezza e fornirebbe molte più informazioni utili in caso di effettiva attività dannosa.

Un motivo non di sicurezza per non farlo: spam di accesso errato.

Gestisco il mio elenco di e-mail / nomi utente sulla tua applicazione. Cerco di accedere a ciascun account con la stessa 'password'. Forse una frase offensiva; slogan politico, o semplicemente un annuncio per qualche sito web.

Poi ognuno dei tuoi utenti accede, quelli con i nomi utente / e-mail che ho indovinato sono costretti a guardare qualunque cosa ho inserito.

Offre a ogni singola persona anonima un vettore per la visualizzazione di contenuti per gli utenti.

Nel caso di colleghi che utilizzano ciascuno il servizio e che possono probabilmente indovinare i rispettivi nomi di accesso, questo potrebbe persino causare molestie o altri problemi relativi alle risorse umane sul posto di lavoro.

Che cosa succede quando voglio accedere alla tua app e sono seduto con il mio collega? Supponiamo che io abbia sbagliato a digitare la mia password. Devo ora mandarlo via mentre accedo, in modo che non veda la mia password tentare?

Se ci sono utenti con nomi utente / indirizzi email simili, potrebbero accidentalmente tentare di accedere all'account di un altro utente.

Un utente malintenzionato potrebbe quindi utilizzare il proprio elenco di tentativi di password "errati" per entrare in account con nomi utente / indirizzi email simili (ad esempio bill11, bill1, ecc.).

Penso che sarebbe meglio elencare semplicemente i tentativi di accesso errati e di successo con il tempo e l'indirizzo IP pertinente.

Sono d'accordo con altre risposte, sottolineando che è facile indovinare la password di un utente se un utente malintenzionato ottiene una sospensione dell'elenco dei tentativi falliti.

In questo caso, non importa che il tuo sistema non contenga informazioni sulle transazioni monetarie. È normale che gli utenti utilizzino la stessa password, o varianti sulla stessa password, su più siti. Potrebbero essere avvisati di non farlo, ma succede ancora. Quindi, solo perché non ritieni che il tuo sistema esponga le informazioni sensibili in sé, non significa che le informazioni sensibili dei tuoi utenti non siano messe a rischio se il tuo sistema è compromesso.

Se Joe User utilizza la stessa password del sistema utilizzata per la sua banca, se un utente malintenzionato è in grado di indovinare la sua password sul sistema e ha scoperto quale banca Joe ha utilizzato, l'utente malintenzionato potrebbe ottenere l'accesso al conto bancario di Joe. O cartelle cliniche o qualsiasi altro sistema su cui ha usato la password.

Non stai solo proteggendo le password per il tuo sistema.

Sospetto che il tuo cliente soffra di un problema XY . Questo significa fare un passo indietro e cercare di capire cosa vuole veramente il tuo cliente. Spesso è utile sapere che qualcuno ha provato una password errata e come è stata inserita questa password, non necessariamente quale password era. Forse il cliente vuole solo informazioni sufficienti per distinguere le minacce benigne, come la fat-fingering della tua password, da quelle più sospette, come indovinare le password da metà del paese su un dispositivo che non ha mai effettuato l'accesso prima.

Quindi chiedi al tuo cliente del modello di minaccia e vedi se le seguenti informazioni sono sufficienti:

• ID utente per il quale l'autenticazione è fallita (in modo che tu possa sapere chi avvisare per ogni errore)
• data e ora
• indirizzo IP del client, agente utente e geolocalizzazione approssimativa
• se il client esegue JavaScript (gli hacker spesso non si preoccupano)
• se il client ha presentato un cookie per aver eseguito correttamente l'accesso in passato

Quindi presenta una finestra di avviso basata su queste informazioni quando un utente accede con successo dopo uno o più errori.

Una possibile soluzione: dal momento che il problema riguarda la memorizzazione di tentativi di password errati in testo in chiaro, evitarlo. Quando viene impostata la password di un utente, generare una chiave pubblica e una coppia di chiavi private. Memorizzare la chiave pubblica e la chiave privata crittografate con la password. Quando si registrano password errate, crittografarle con la chiave pubblica (e aggiungere sale). In questo modo, solo l'utente che conosce la password corretta può vedere le password errate.

Esito ad aggiungere alle risposte già eccellenti qui, ma c'è un altro punto importante. A meno che tu non sia assolutamente certo che gli utenti si colleghino al sito tramite HTTPS (e sinceramente, nemmeno allora) non si dovrebbe mai nemmeno avere l'opportunità di visualizzare le password errate ... poiché non dovrebbero mai essere trasmesse (crittografate o meno) nel primo posto. I sistemi client devono solo trasmettere qualcosa come un hash salato, non la vera password (in una corretta implementazione, per garantire che l'hash stesso non diventi la password, cioè qualcosa che possa essere rubato e riutilizzato), per prevenire attacchi di intercettazione.

E non importa che il sito non stia elaborando transazioni finanziarie. Non vuoi ancora che diventi l'anello più debole in qualche catena.

Quindi sono pienamente soddisfatto del tuo lead dev su questo. Combatterei con le unghie e con i denti contro questa "caratteristica".

Il tuo sistema avrà un ampio database decifrabile di password. Guardando le password errate per l'utente X, otterrai quasi ma non le password corrette per l'account di X, le password corrette per i diversi account dell'utente X, oltre alle password corrette per gli account degli utenti con quasi lo stesso nome utente di X.

Con la ragionevole supposizione che un hacker possa penetrare nel tuo sistema e ottenere una copia decifrata del database, ciò sarebbe disastroso. Anche supponendo che l'accesso al proprio sistema da parte della persona sbagliata non sia troppo critico, quel database conterrà password degli utenti per sistemi diversi che potrebbero essere molto più critici.

Mi sembra che in un'autenticazione costruita correttamente, la password che l'utente ha digitato non viene nemmeno trasmessa al sito host, quindi la domanda di archiviare tentativi errati è discutibile.

Potrebbe essere accettabile la casella di controllo "vedi password" nell'interfaccia, che è strettamente una funzione locale e potrebbe essere utilizzata come password viene digitato o dopo un tentativo fallito. Probabilmente le informazioni salvate dovrebbe essere cancellato dopo un breve periodo di tempo per impedire la raccolta delle password da console abbandonate.