Domanda:
C'è qualche motivo per non mostrare agli utenti le password immesse in modo errato dopo un accesso riuscito?
RaunakS
2016-09-09 23:35:54 UTC
view on stackexchange narkive permalink

Il nostro cliente ha stabilito che, nel caso in cui il nome utente in questione abbia avuto più tentativi di accesso non riusciti, la password immessa in modo errato deve essere visualizzata una volta eseguito correttamente l'accesso. Le informazioni inserite correttamente, comprese le password precedenti, non verranno visualizzate in ogni caso.

Il nostro sviluppatore principale ci ha detto che è tecnicamente possibile non eseguendo l'hashing di voci errate, ma è estremamente a disagio con la funzione e quindi è stata messa in attesa durante il brainstorming.

Il sito Web in questione è un'ampia applicazione di mappatura / GIS che non presenta alcuna transazione monetaria qualunque cosa. Altre opzioni di accesso / autenticazione includono Google / LinkedIn / Twitter / Facebook, quindi ovviamente nessuna password da memorizzare lì e la gestione che è principalmente un problema di UX.

Quali vulnerabilità di sicurezza derivano dall'implementazione di tale funzionalità? Il nostro cliente non è del tutto privo di conoscenze tecniche, quindi è sufficiente una spiegazione generale.

Mi scuso se la domanda è troppo ampia o la risposta è molto ovvia.

Chiedi al cliente perché.Quindi chiedi il motivo di qualunque cosa dicano.Potrebbero avere un'idea, ma sicuramente non vogliono farlo.
enorme responsabilità legale - non implementare a meno che tu non abbia il cliente a rimuovere tutti gli obblighi legali da parte della tua azienda
Cosa dice @timpone.Perché, come chiunque in infosec sa perfettamente, gli esseri umani spesso hanno 100 account (io ne ho 154) e nessun essere umano può ricordare tutto questo, il riutilizzo avviene.Anche se il tuo sito ha poco da perdere, e anche se l'utente condivide la sua password con altri siti con poco da perdere (ad es. FooFlix, cosa farà, riprodurrà alcuni film?) Immagina la sua sorpresa quando un hacker * trova un modo * (ad esempio, l'acquisto di migliaia di dollari di abbonamenti regalo).
(Convinci il tuo cliente e) vai con le informazioni standard del salvaschermo: * "Sono stati X tentativi di accesso falliti" *.
Mostra loro un registro SSH da un server pubblico, mostra come registra continuamente gli accessi non riusciti da tutto il mondo.Il contenuto più probabile di quel registro sarà 100 Mb di tentativi di "password", "1234", ecc. - Non utile per qualcuno per vedere * ogni accesso *.Se si cancella il registro dopo un accesso riuscito, qualcuno non saprà mai se qualcun altro ha effettuato l'accesso come loro dopo aver indovinato la password alcune volte.Se non lo fai, vedrai per sempre errori di battitura precedenti che conosci e non ti interessano.E se vedi due accessi falliti, a che serve comunque?Chi beneficia in qualche modo di questa "caratteristica"?
Tricky ... Io per primo ho un (grande) set di password che uso su vari siti, quindi anche se una password potrebbe essere errata su un sito, sarebbe comunque corretta su molti altri siti.Successivamente, preferirei che un sito non sembrasse memorizzare le mie password "errate", né me le restituisse ** in chiaro ** affinché chiunque le leggesse!
Fornisci invece un pulsante su cui un utente può fare clic per mascherare / smascherare il campo della password.Le password non dovrebbero essere visualizzate a meno che l'utente non se lo aspetti.
È possibile memorizzare in modo sicuro le password errate.Ma le risposte fornite finora ti danno già ragioni sufficienti per non farlo.Quindi non ti darò l'algoritmo.Invece ti dirò che le password appartengono agli utenti.Le password non appartengono al tuo client.Quello che il tuo cliente ti chiede di fare è abusare di quelle password.Devi chiederti se vuoi davvero aiutare il tuo cliente ad abusare dei suoi utenti.Ciò di cui hai veramente bisogno è il miglior argomento possibile per convincere il tuo cliente a scegliere una soluzione adeguata.
Forse il tuo client intendeva mostrare il numero di password immesse in modo errato invece delle password effettivamente errate.Il primo è quello che fa anche SAP.Quest'ultimo è inaudito.
Questa è un'idea terribile.Il problema dell'hashing e il problema dell'esposizione di nome utente / password dell'account incrociato dovrebbero escludere questa idea.Cerco sempre le risposte a problemi come questo e penso che se questo fosse un buon modello, posti come google ecc. Lo userebbero.Segnalalo al tuo cliente insieme a tutti i punti già menzionati.Ricorda sempre ai clienti che la ruota raramente ha bisogno di essere reinventata.
** Cattivo cattivo cattivo: ** `hunter3`,` junter2`, `hunrer2` e ora conosci la mia password.
Conosco un sito web che lo fa (o almeno lo fa).E ho approfittato di questa "funzionalità" per aggirare il ToS di questo sito web sulla non condivisione delle informazioni di contatto con altri utenti.
Dammi il cinque allo sviluppatore principale che ha espresso disagio e ha provocato questo problema!
Se potessi misurare quanto fosse diversa dalla password originale potresti mostrare errori di battitura, ma poi dovresti memorizzare le tue password senza hash.
solo aggiungendo ingredienti alle già ottime risposte sopra, usa questo sito per vedere https://haveibeenpwned.com/
In generale, se trovassi un progetto Open Source che fa questo, probabilmente gli assegnerei un identificatore CVE poiché questo sarebbe generalmente considerato una vulnerabilità di sicurezza.
come amministratore di sistema, è utile per caratterizzare i tentativi falliti in qualche modo, per distinguere tra un utente che cerca di ricordare e digitare la propria password e una sorta di attacco.Nel primo caso, offri l'aiuto dell'utente.In quest'ultimo caso, avviare misure difensive.
il tuo lead dev è intelligente, non lasciarla andare
Due parole: errori di trasposizione.
Se incontrassi un sistema che mi presentasse le mie password in chiaro e digitate in modo errato, chiuderei il mio account e smetterei di usare quel sistema e consiglierei ad amici e parenti di evitare quel servizio.È praticamente garantito che se ho digitato la password in modo errato, viene fuori un carattere o ho digitato una delle mie password da un account diverso.In ogni caso, è negligente per qualsiasi azienda tenere un elenco delle mie password errate.Questa è solo un'idea terribilmente cattiva.
Tredici risposte:
#1
+355
PwdRsch
2016-09-10 00:08:45 UTC
view on stackexchange narkive permalink

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

Il rischio maggiore è se questo database di password non valide diventa accessibile agli aggressori. O compromettono il server, eseguono SQL injection o lo recuperano in qualche altro modo. Piuttosto che decifrare le password primarie, che si spera siano fortemente hash e quindi obiettivi più difficili, potrebbero decidere di compromettere gli account utilizzando le informazioni nella cronologia delle password non valide. O accedono facilmente alle password in testo normale o tentano di trovare la chiave di crittografia che consente loro di decrittografare nuovamente le password in testo normale.

Una fonte comune di errori di accesso sono errori di battitura minori durante il processo di immissione della password. Quindi la mia password è Muffins16 ma digito mUFFINS16 perché il mio blocco maiuscole è attivo. O Muffins166 perché ho premuto due volte lo stesso tasto. Oppure Muffina16 perché il mio dito ha premuto il tasto sbagliato. Come puoi vedere, queste variazioni sono abbastanza vicine all'originale che gli aggressori possono probabilmente determinare la password valida dalle password non valide provando alcune piccole modifiche o confrontando le password errate con le parole o i nomi del dizionario.

Questo problema è esacerbato perché la maggior parte delle persone utilizza scelte di password simili a questi formati e non stringhe casuali. È più difficile per un utente malintenzionato identificare l'errore di battitura se la password non valida è V8Az $ p4 / fA, sebbene sia ancora molto più facile provare varianti di quella quindi indovinarla senza alcuna informazione.

Un altro rischio è che gli utenti potrebbero non ricordare quale delle loro password hanno utilizzato su questo sito, quindi provano quelle comuni. Ora questo sito è improvvisamente un obiettivo più grande perché un utente malintenzionato potrebbe essere in grado non solo di compromettere l'account di un utente lì, ma anche su altri siti con il pratico elenco di password "non valide".

Puoi mitigare alcune di queste rischi cancellando l'archiviazione 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 porre al tuo cliente è come prevede che gli utenti trarranno vantaggio dal vedere le loro password non valide. È così che gli utenti possano identificare come hanno digitato male la loro password? Gli errori di battitura non sono intenzionali, quindi è improbabile che mostrare loro l'errore migliorerà i futuri tentativi di accesso. Quindi gli utenti possono identificare un utente malintenzionato che cerca di indovinare le proprie password? Un feedback simile può essere fornito elencando data, ora, IP / geolocalizzazione o altre informazioni per tentativi non validi senza la password tentata. Quindi gli utenti sanno che hanno sbagliato durante l'immissione della password e non incolpano il sistema di accesso del sito? Sembra l'unico con merito e non sono sicuro che fornisca un valore sufficiente per giustificare il rischio.

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

Qual è la tua email così posso provare con la password Muffins16?Voglio dire, discutere ulteriormente questo argomento importante con te?
Ovviamente questo è un trucco, la vera password * è * mUFFINS16.
Rompere il database sarebbe * estremamente * facile: basta provare 1000 tentativi di password errata su diverse dozzine di account prima di rubare il database crittografato.Voilà, ora hai diverse migliaia di password errate "note in chiaro" nel database da cui puoi ricavare la chiave di crittografia.
@Wildcard um, cosa?Perché il testo in chiaro noto aiuta a decifrare la chiave di un moderno algoritmo crittografico?
Almeno una password di root del sistema è stata compromessa dall'elenco delle password errate.
@Ben Penso che il suo punto sia quello di decifrare le password sbagliate memorizzate nel database.Supponendo che siano archiviati crittografati.Se un utente malintenzionato ha o avrà accesso ai dati dal DB, avere una gamma molto ampia di input noti aiuterà a invertire l'output, rivelando quindi la crittografia utilizzata, il che significa che avrai quindi facile accesso a qualsiasi password errataarchiviati nel database.
Un voto positivo non è stato sufficiente per questa straordinaria risposta.Apprezzo davvero il tuo contributo ..
@vlaz il punto è che la crittografia moderna non è vulnerabile a un [attacco di testo in chiaro noto] (https://en.wikipedia.org/wiki/Known-plaintext_attack) quindi avere un numero qualsiasi di testi in chiaro noti non ti aiuterà a decifrare le password crittografate.
Un altro grosso problema è il surf con le spalle.Non ho bisogno di crackare il tuo server se semplicemente guardando lo schermo di qualcuno si ottiene lo stesso.E, naturalmente, se il CEO ha lesinato su un certificato SSL, hai problemi molto più grandi di quello, quindi potresti anche non esacerbarli ulteriormente.
A parte il fatto che l'idea generale non è poi così eccezionale;il rischio principale identificato qui potrebbe essere mitigato accumulando tentativi di password errate in un cookie piuttosto che archiviarli in modo persistente lato server, o anche solo farlo interamente lato client con archiviazione locale?Perderai la possibilità di vedere gli accessi non riusciti da altre macchine ... ma non è davvero chiaro che sia un requisito dalla descrizione dell'OP.
Se l'intenzione è quella di mostrare come gli utenti digitano male le proprie password, l'opzione più sicura sarebbe quella di fornire un pulsante per mostrare la password durante la digitazione.E sarebbe meglio non inviare il valore visibile;cioè, il valore "
@JasonC: purtroppo la memorizzazione delle password nei cookie comporta lo stesso rischio in quanto possono essere utilizzate per indovinare la password dai tentativi falliti.Anche se i cookie sono crittografati, la chiave deve essere archiviata da qualche parte.Se quella chiave viene compromessa, il gioco finisce (accedere ai cookie è molto facile se si ha accesso fisico al dispositivo e relativamente facile se è possibile inserire del codice nel sistema).
@lepe Non hai bisogno di un cookie per questo.Quando il server risponde con un tentativo di accesso non riuscito, il client non potrebbe memorizzare questi valori localmente, in memoria?Quindi, una volta che il server risponde finalmente con un Login OK, il client può mostrare tutte le password che ha in memoria.Niente di tutto ciò richiede la memorizzazione di password non hash sul lato server o in un cookie, e così facendo non si introducono più rischi di quelli coinvolti nella raccolta e nell'invio delle credenziali di accesso in primo luogo.
Un altro problema sarebbe che le persone dimenticassero la password che hanno usato per il tuo accesso.Immagino che ci sia un numero considerevole di utenti che utilizza una manciata di password su tutti gli account.Se uno non funziona, si limita a scorrere l'elenco finché uno non funziona.Salvare i loro tentativi falliti significa salvare le password effettive su altri siti.
@Andonaeus: sì, questa è una possibilità.Non mi è ancora chiaro quale sia la loro intenzione dietro quella richiesta.Se vogliono mostrare un tentativo di accesso (cosa che penso potrebbe essere il caso), quello di cui stiamo discutendo qui è un animale completamente diverso.
Qualunque cosa tu faccia, la password errata verrà temporaneamente archiviata da qualche parte nella memoria.Normalmente, per mantenerlo più a lungo, è sufficiente memorizzare la password in una sessione, che è temporanea e normalmente solo in memoria e non in una memoria persistente.Francamente, qual è il vero rischio aggiunto in questo caso che le password errate vengano archiviate per un periodo di tempo più lungo (minuti?) Mentre l'utente effettua l'accesso?Per eseguire anche l'hash, ovviamente devi avere la password in memoria, quindi non otterrai mai la perfezione comunque.
@corsiKa I miei figli mi dicono che se la password è Muffins16, l'indirizzo email deve essere [email protected]
#2
+199
TTT
2016-09-10 00:03:16 UTC
view on stackexchange narkive permalink

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.

Un'altra vulnerabilità: una volta effettuato l'accesso con successo, chiunque guardi anche il tuo schermo può vedere i tentativi non riusciti _senza nemmeno dover accedere al database_.
Inoltre, non è possibile eliminare la password corretta (fiocco batteria a cavallo) una volta che è stato eseguito l'hash;devi aspettare fino a dopo che è stato controllato per sapere se conservarlo o eliminarlo.
@GhillieDhu Questa è una finestra di tempo molto breve e la password sarebbe solo nella RAM.(E la password era * già * nella RAM in modo da poterla hash, tenerla lì per qualche millisecondo in più non farà nulla di significativo)
Il paragrafo più in basso di questa risposta è praticamente il più schiacciante degli esempi che dimostrano che questo non dovrebbe ** MAI ** essere fatto.
Non dovrebbe dire tsdr ;?
#3
+95
user15392
2016-09-09 23:38:27 UTC
view on stackexchange narkive permalink

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.

Se voglio craccare il tuo account drewbenn, tutto quello che devo fare è impostare alcuni tipi comuni di nome utente: drewben / derwbenn / ... e attendere finché non digiti erroneamente il tuo nome utente e inviami la tua password: -o
@Falco dovresti aggiungerlo come risposta.Questo è un buon modo per attaccare attivamente gli utenti su un sistema come questo (e qualcosa che sarebbe invisibile al bersaglio, assumendo la comune (e buona) misura di sicurezza in cui "password sbagliata" restituisce lo stesso codice di errore di "utente non valido").
#4
+44
John Wu
2016-09-10 02:39:07 UTC
view on stackexchange narkive permalink

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.

Bella alternativa!Potrebbe essere esteso per includere anche informazioni statistiche su quanto fossero vicine le password errate a quella reale, come "4% di differenza".Quindi l'utente può giudicare ancora meglio quali sono stati i suoi tentativi di accesso falliti e quali erano i tentativi di hacking.Difficile da implementare, tuttavia, poiché possiamo accedere in sicurezza solo a una password non riuscita o alla password reale in chiaro (all'accesso prima dell'hashing) e non possiamo memorizzarli.Forse possibile con [crittografia funzionale] (https://en.wikipedia.org/wiki/Functional_encryption)?
@tanius no, il sito ** non ** dovrebbe essere in grado di calcolare quella differenza!
La tua alternativa menzionata è ciò che accade su Steam quando il tuo account è stato compromesso ma l'attaccante non ha accesso al tuo secondo fattore di autorizzazione.Ti verrà mostrato quale dispositivo sta tentando di ottenere l'accesso in modo da poter verificare se hai sbagliato qualcosa o se sei sotto attacco.Funziona abbastanza bene ed è molto meglio di quanto proposto dal client di OP.
@guntbert, nel momento in cui vengono mostrate * le password errate *, la password corretta è disponibile per il confronto anche se correttamente hash, perché l'utente l'ha appena inserita.
@Ben Giusto, ma il problema è memorizzare le password errate (non è possibile eseguire l'hashing).
Perché ci fidiamo di Mark con la data di miliardi di persone quando ha dimostrato di essere una persona inaffidabile che cerca attivamente di hackerare le persone?
#5
+39
Joshua Hunter
2016-09-14 02:30:19 UTC
view on stackexchange narkive permalink

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.

Questa è una questione molto importante che penso non abbia ricevuto abbastanza attenzione.
Non ci avevo pensato prima, ma in realtà è un problema di sicurezza.
#6
+23
sixtyfootersdude
2016-09-10 02:22:18 UTC
view on stackexchange narkive permalink

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?

"Cosa succede quando voglio accedere alla tua app e sono seduto con il mio collega?"- Conosco qualcuno il cui intero laboratorio, come studenti di dottorato, si è allenato a leggere le password gli uni degli altri osservandole mentre le digitavano.Aiuta a vederlo più volte, a quanto pare.Deve essere stata una risata un minuto laggiù, e se lo fai ti togli tutto il divertimento.Regola di sicurezza numero uno: non essere un guastafeste, mantieni la sfida per gli aggressori.
#7
+17
webbster
2016-09-11 03:53:22 UTC
view on stackexchange narkive permalink

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.

Questo, a me, sembra un rischio molto maggiore del rischio accettato "e se il DB finisse nelle mani sbagliate".Ci sono un numero qualsiasi di sistemi in cui provo a registrarmi, trovo che il mio nome utente preferito sia stato utilizzato e scorro tra gli altri.Dopo un po 'di tempo, ho dimenticato quale ho usato per un determinato sito, quindi devo scorrerli quando provo ad accedere dopo un'assenza.Ma la mia password viene sempre calcolata dal nome del sito più l'anno più altri dettagli, quindi non cambia.Quindi, mentre il DB PU cadere nelle mani sbagliate, ci saranno utenti che vedranno le password corrette di altre persone.
#8
+11
Seth R
2016-09-10 03:17:24 UTC
view on stackexchange narkive permalink

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.

E se digito per errore la mia password bancaria top secret per il tuo sistema, verrà anche ricordata.
#9
+9
Damian Yerrick
2016-09-12 04:20:09 UTC
view on stackexchange narkive permalink

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 casella di avviso potrebbe non essere sufficiente se sono stati effettuati più tentativi.Inoltre, l'utente dovrebbe essere in grado di tornare all'elenco, se lo desidera
Il motivo migliore di gran lunga per non mostrare le vecchie password è infatti che ** non è necessario ** fare qualcosa di così complicato.- Il mio primo pensiero sul perché le persone lo desiderino, è che non credono di avere le dita grasse, nel qual caso potresti semplicemente usare qualcosa come "premi inserisci per mostrare la password" come è implementato nelle principali soluzioni software.
#10
+7
v7d8dpo4
2016-09-10 11:44:06 UTC
view on stackexchange narkive permalink

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.

Questa sembra una soluzione praticabile alla principale preoccupazione.Continua a non vedere la password di altre persone a causa di un accesso accidentale con il tuo nome utente.E ovviamente la soluzione fallisce quando cambi la password.Ma buona idea.+1 da me.
Ciò non impedisce gli attacchi che si basano sull'errata digitazione di [_username_] (http://security.stackexchange.com/a/136483/56961)
Tra tutti gli altri motivi penso che questa sia una cattiva idea, la crittografia e la decrittografia dei dati con chiavi asimmetriche è letteralmente più lenta della crittografia simmetrica.Il carico extra sui tuoi server sarebbe a dir poco ridicolo.
@Craig SSL non richiede più o meno lo stesso carico se non più della crittografia con un codice asimmetrico?
SSL utilizza la crittografia asimmetrica per generare e condividere in modo sicuro una chiave di crittografia simmetrica, che viene quindi utilizzata per crittografare tutti i dati in transito.
È del tutto possibile che fosse molto tardi quando ho creato quel commento e l'ho formulato in modo più severo di quanto avrei potuto fare altrimenti.:)
#11
+7
Viktor Toth
2016-09-11 09:53:30 UTC
view on stackexchange narkive permalink

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".

In modo che il server debba memorizzare, cosa, l'hash salato generato dal client?In che modo questo è funzionalmente diverso dal semplice invio della password su un canale sicuro e lasciare che il server l'ha hash utilizzando un vero algoritmo di digest della password come pbkdf2, bcrypt o scrypt, nessuno dei quali è implementato nei browser web (a) e (b) se ilil client invia un hash, tutto ciò che sta facendo è provare che conosce l'hash, non che conosce la password effettiva, che in definitiva è meno sicura dell'invio della password e della crittografia reale sul server.
Esistono implementazioni di bscrypt / scrypt in JavaScript.E il doppio hashing può garantire che ciò che il client invia non diventi la password (non può essere riutilizzato).La mia preoccupazione con qualsiasi implementazione sarebbe il modo in cui un sale non prevedibile per il secondo hash viene creato, archiviato e inviato al client.
Se il server sta inviando JavaScript al client per l'hash della password, stai ancora estendendo lo stesso livello di fiducia al proprietario del server, inoltre stai fornendo l'opportunità a un uomo nel mezzo di inviarti uno script modificato, oltre a rimuovere la possibilità per il server di eseguire facilmente la versione, aggiornare e controllare il protocollo crittografico in uso, oltre a esporre a qualsiasi potenziale aggressore esattamente quale protocollo stai utilizzando e quanti round, ecc. Vedo ancora più problemi che vantaggi, rispettosamente.
Se capisco correttamente il tuo punto, stai dicendo che poiché il JS stesso proviene dal server, un man-in-the-middle ha la stessa opportunità di rubare la password come se fosse stata inviata senza hashing / crittografia.Quindi è necessario un canale protetto e un canale protetto allevia i problemi associati all'invio di una password non crittografata.Ho digerito correttamente il tuo punto?
Essenzialmente, ma questo è solo uno dei miei punti.Quel canale sicuro è HTTPS con forward secrecy ed esiste già.Se un server ti sta inviando uno script per elaborare la tua password, il server potrebbe anche elaborare la tua password presumendo che il canale sia sicuro.Non vi è alcun guadagno netto dall'hashing sul client, tuttavia ci sono molti potenziali problemi con l'hashing sul client.
E le seguenti preoccupazioni: 1) invece di una CPU, ora due CPU hanno la password in chiaro, almeno temporaneamente;2) cosa succede se il canale non è sicuro dopo tutto?Non ha senso stabilire un "gold standard" di autenticazione sicura anche su http?Le mie priorità sono mal riposte qui?
Se il canale non è sicuro, l'hashing sul client non è utile poiché un man-in-the-middle può facilmente catturare l'hash e riprodurlo.Se hai intenzione di sviluppare un protocollo di stretta di mano che fa una piccola danza di sfida / risposta avanti e indietro per stabilire uno scambio sicuro, beh, potrei suggerire HTTPS?:-) La CPU non conserva le informazioni (beh, a parte la cache della CPU, che può o meno essere svuotata durante i cambi di contesto, ma non confondiamoci con questo).La RAM e le cache su disco sono una questione diversa, tuttavia, sia sul server * che sul * client.
Sono rispettosamente in disaccordo con la prima parte, perché se il server invia un salt una tantum e il client esegue l'hashing con quel sale (questo è il punto del doppio hashing; primo hash con salt fisso che è stato utilizzato per memorizzare la password sul server,secondo, hash con sale una tantum; hash del server con lo stesso sale una tantum da confrontare), l'hash non è riutilizzabile tramite replay.Ma capisco i tuoi punti sugli attacchi man-in-the-middle.Spunti di riflessione, grazie.
Abbiamo ricevuto l'avviso "chat".Ma quello che stai suggerendo richiede che il server passi entrambi i sali al client, perché non si può certo contare sul client per ricordare il sale originale.Quando l'hash della password è stato originariamente memorizzato sul server, la password in chiaro doveva essere passata al server, oppure l'hash salato originale doveva essere inviato ed era intercettabile.E come ho detto in precedenza, questo rende cose come il controllo delle versioni dell'algoritmo di hashing delle password più difficili e soggette a errori.Vedo solo un sacco di buchi in questo.;-)
#12
+4
gnasher729
2016-09-10 20:21:29 UTC
view on stackexchange narkive permalink

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.

#13
  0
ddyer
2016-09-15 23:03:12 UTC
view on stackexchange narkive permalink

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.

Eh?La password che inserisci su un sito web viene sempre trasmessa al server host per essere verificata.Non posso fidarmi del client per l'autenticazione contro se stesso e l'hashing / offuscamento lato client è piuttosto inutile.La password viene _speratamente_ trasmessa utilizzando SSL / TLS, quindi è crittografata durante il transito, ma _è_ inviata al server a prescindere.
No, qualche variazione di;il server ti dà una stringa casuale, tu hash la password con la stringa casuale e la ritrasmetti al server, il server confronta ciò che hai inviato con il risultato atteso, dimostrando che conosci la password.
_E_ dimostrando che il server memorizza tutte le password in chiaro.Altrimenti non può fare l'hashing.Quindi questa è una soluzione molto peggiore.
Non necessariamente, dipende dal protocollo di hashing esatto.Ad esempio, l'hash della password con un metodo noto e fisso, che teoricamente riproduce ciò che il server memorizza.Quindi hash il risultato con il casuale appena presentato (evitando attacchi di replay).
@ddyer come stai proponendo che il server conosca il risultato atteso, a meno che il server non stia eseguendo l'hashing della password utilizzando lo stesso algoritmo per eseguire il confronto?Una stretta di mano ben controllata per stabilire un canale sicuro è ciò che riguarda HTTPS.La crittografia personalizzata è difficile da eseguire correttamente.
Quindi, il server ha avuto la password in chiaro ad un certo punto, al fine di eseguire il primo hashing e memorizzarla.Oppure, il client lo ha inviato pre-hash, anche la prima volta.Ma in quel caso, l'hash _è_ il testo in chiaro, quindi è inutile.Ma supponiamo che il server abbia eseguito il primo hashing dal vero testo in chiaro e che il client abbia fatto lo stesso.All'accesso, ognuno esegue un secondo round utilizzando un nonce concordato e confronta i risultati.Ma poi il client deve conoscere l'intera strategia di hashing del server.Il server non può tenere per sé sali, segreti o algoritmi;qualsiasi tentativo di accesso dovrebbe rivelarlo tutto
Hai ragione sul fatto che la password con hash sia effettivamente la password, ma la domanda è cosa sia peggio;presumendo che la password memorizzata del server sia compromessa o assumendo che l'accesso momentaneo del server alla password in chiaro (e alle password non riuscite) sia un rischio.Ad esempio, i recenti attacchi SSL avrebbero rivelato che le password venivano trasmesse "in modo sicuro" al server, ma avrebbero rivelato solo hash inutili se il protocollo non avesse mai trasmesso password reali.Alla fine, tutto dipende dal tuo modello di minaccia.


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...