tldr; questo è anche peggio che non eseguire l'hashing delle password e memorizzarle come testo normale.

Sono d'accordo con le preoccupazioni del tuo sviluppatore principale. Per mostrare i precedenti tentativi di password errati, è necessario memorizzarli in modo reversibile, il che significa che non possono essere sottoposti a hashing. Se qualcuno ha compromesso il sistema, avrebbe accesso a tutti i tentativi sbagliati e probabilmente potrebbe ricostruire quali sono le vere password per alcuni utenti. Ad esempio, se puoi vedere alcuni dei miei tentativi sbagliati sono stati:

  corretta batteria orrenda graffetta corretta battteria cavallo  

Sarebbe abbastanza facile capirlo la mia password effettiva.

Sono anche d'accordo con la risposta di drewbenn: se digito il mio nome utente in modo errato ma con la mia password corretta e il nome utente errato sembra essere il nome utente di qualcun altro, ora quell'utente può vedere la mia vera password.

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

Poi ci sono state tutte le volte che ho usato la password sbagliata quando ho provato ad accedere a un account condiviso.

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

Oltre a tutti gli errori di battitura quando qualcuno è in piedi sopra la mia spalla mentre io " sto effettuando l'accesso.

E in tutti questi casi, a volte ho inserito la mia password gmail o lastpass nella richiesta della password al lavoro, e viceversa.

E le volte che ho ho cercato su Google la mia password perché non stavo guardando lo schermo e pensavo fosse bloccato. Non che abbia nulla a che fare con la tua proposta, ma mi piace condividere quell'aneddoto perché ricorda alle persone che tutti possono commettere errori e digitare la cosa sbagliata a volte.

l'unica cosa che fa questa hUnt3r2feature è trasformare piccoli errori (inserendo una password sbagliata o digitandola male) in esposizioni accidentali a un pubblico più ampio.

Perdita di reputazione

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

Mark (Zuckerberg) ha utilizzato il suo sito, TheFacebook.com, per cercare membri del sito che si sono identificati come membri dei Crimson. Quindi ha esaminato un registro di accessi falliti per vedere se qualcuno dei membri di Crimson avesse mai inserito una password errata in TheFacebook.com. Se i casi in cui erano stati inseriti non erano riusciti, Mark ha provato a utilizzarli per accedere agli account di posta elettronica di Harvard dei membri di Crimson. Ha avuto accesso a due di essi.

In altre parole, Mark sembra aver utilizzato i dati di accesso privati ​​di TheFacebook per hackerare gli account di posta elettronica separati di alcuni utenti di TheFacebook.

Fonte: In che modo Mark Zuckerberg è entrato nell'Harvard Crimson

Un'alternativa

Se il tuo cliente è determinato a mostrare fallito tentativi di accesso al successivo accesso riuscito, come una sorta di misura di benessere, posso suggerire un'alternativa? Invece di visualizzare le password non riuscite, visualizza l'indirizzo IP e le informazioni di geolocalizzazione del browser che ha inviato la password errata. Dovrebbe essere abbastanza facile da fare, non causerebbe problemi di sicurezza e fornirebbe informazioni molto più utili in caso di attività dannose effettive.

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

Eseguo il mio elenco di email / nomi utente contro la tua applicazione. Tento di accedere a ciascun account con la stessa "password". Forse una frase offensiva; slogan politico o semplicemente un annuncio per qualche sito web.

Quindi ognuno dei tuoi utenti accede, quelli con i nomi utente / email che ho indovinato sono costretti a guardare qualunque cosa io abbia inserito.

Fornisce a ogni singola persona anonima un vettore per la visualizzazione del contenuto ai tuoi utenti.

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

Cosa succede quando voglio accedere alla tua app e sono seduto con il mio collega? Supponiamo che io abbia digitato male la mia password. Ora devo mandarlo via mentre effettuo l'accesso in modo che non veda il mio tentativo di password?

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

Un utente malintenzionato potrebbe quindi utilizzare il proprio elenco di tentativi di password "errate" per accedere ad account con nomi utente / indirizzi email simili (ad es. bill11, bill1 e così via).

Penso sarebbe meglio elencare semplicemente i tentativi di accesso non validi e riusciti insieme all'ora e all'indirizzo IP pertinente.

Sono d'accordo con altre risposte che sottolineano che rende facile indovinare la password di un utente se un utente malintenzionato si è impossessato dell'elenco dei tentativi falliti.

Stando così le cose, non importa che il tuo sistema non contenga alcuna informazione sulla transazione monetaria. È normale che gli utenti utilizzino la stessa password o varianti sulla stessa password su più siti. Potrebbe essere consigliato di non farlo, ma succede comunque. Quindi, solo perché non ritieni che il tuo sistema esponga di per sé informazioni sensibili non significa che le informazioni sensibili dei tuoi utenti non siano messe a rischio se il tuo sistema viene compromesso.

Se Joe User utilizza la stessa password sul tuo sistema come usa per la sua banca, se un utente malintenzionato fosse in grado di indovinare la sua password sul tuo sistema e scoprisse quale banca ha utilizzato Joe, potrebbe accedere al conto bancario di Joe. O le cartelle cliniche o qualsiasi altro sistema su cui Joe ha utilizzato quella password.

Non stai solo proteggendo le password del tuo sistema.

Sospetto che il tuo cliente soffra di un problema XY. Ciò 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 fosse quella password. Forse il client vuole solo informazioni sufficienti per distinguere le minacce benigne, come la diteggiatura della propria password, da quelle più sospette, come indovinare le password dall'altra parte del paese su un dispositivo che non ha mai effettuato l'accesso prima.

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

• ID utente per cui l'autenticazione non è riuscita (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 aggressori spesso non si preoccupano)
• se il client ha presentato un cookie per aver effettuato 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: poiché la preoccupazione qui è di memorizzare i tentativi di password errati in testo normale, evitalo. Quando viene impostata la password di un utente, generare una chiave pubblica e una coppia di chiavi private. Memorizza la chiave pubblica e la chiave privata crittografata con la password. Quando si registrano password errate, crittografale con la chiave pubblica (e aggiungi salt). In questo modo, solo l'utente che conosce la password corretta può vedere le password errate.

Esito ad aggiungere alle già eccellenti risposte qui, ma c'è un altro punto importante. A meno che tu non sia assolutamente certo che gli utenti si connettono al sito solo tramite HTTPS (e sinceramente, nemmeno allora) non dovresti mai nemmeno avere la possibilità di visualizzare le password errate ... in quanto non dovrebbero mai essere trasmesse (criptate o meno) nel primo posto. I sistemi client dovrebbero trasmettere solo qualcosa come un hash salato, non la password effettiva (in una corretta implementazione, per garantire che l'hash stesso non diventi la password, cioè qualcosa che può 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 di una catena.

Quindi sono pienamente d'accordo con il tuo sviluppatore principale su questo. Combatterei con le unghie e con i denti contro questa "caratteristica".

Il tuo sistema avrà un grande database di password decifrabile. Cercando le password errate per l'utente X, otterrai password quasi ma non del tutto corrette per l'account X, password corrette per diversi account dell'utente X, oltre a password corrette per account di utenti con quasi lo stesso nome utente di X.

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

Mi sembra che in un'autenticazione costruita correttamente, la password digitata dall'utente non venga nemmeno trasmessa al sito host, quindi la questione della memorizzazione dei tentativi errati è discutibile.

Potrebbe essere accettabile avere una casella di controllo "vedi password" nell'interfaccia, che è strettamente una funzione locale, e potrebbe essere usata sia come password che viene digitata o dopo un tentativo fallito. Probabilmente le informazioni salvate dovrebbero essere cancellate dopo poco tempo per impedire la raccolta di password da console abbandonate.