Non è necessario forzare brutemente un hash per rubare una password. Un sito Web potrebbe essere compromesso da un utente malintenzionato in modo che possa leggere le password direttamente dal modulo di accesso, in testo normale. Oppure il proprietario del sito web potrebbe farlo, potrebbe sempre farlo se lo desidera, dipende da te se ti fidi del proprietario o meno (non vorrai usare la stessa password su Facebook e SomeBlackHatCommunity dot com). Inoltre, c'è sempre il buon vecchio surf da spalla per rubare le password. Una password è come una chiave e, utilizzando la stessa password, stai effettivamente dando la stessa chiave a porte diverse a persone diverse. Puoi vedere che non è mai una buona idea.

Quindi non dovresti mai usare la stessa password in posti diversi, a meno che quella password non protegga gli stessi dati o ti dia gli stessi privilegi, quindi ad esempio, credo che tu possa usare la stessa password per proteggere i tuoi backup.

TL; DR: non ho bisogno di recuperare la TUA password, devo solo trovare una stringa che generi lo stesso hash e poiché non controlli l'hash che lo sviluppatore del sito web utilizza fino a quando non ne utilizza uno sicuro , non aiuta tanto quanto costa. E se sono dopo te continuo ad hackerare i siti web che usi finché non ne trovo uno debole. Oppure uso un altro metodo.

XKCD pertinente:

https://www.xkcd.com/936/

Perché se non c'è un XKCD pertinente , presto ci sarà.

Il riutilizzo delle password rappresenta un rischio terribile per gli utenti perché in caso di violazione dei dati,

Solo se quella password protegge qualcosa che conta.

Per l'utilizzo generale dei forum su Internet, ho un nome di battaglia con il proprio indirizzo e-mail e quattro o cinque password per tutto.

Queste password proteggono nulla . Anche compromettere l'account di posta elettronica dietro di loro non ti dà altro che la capacità di far sembrare il mio nome di battaglia più stupido di quanto già sembri.

con le password non archiviate in modo sufficientemente sicuro,

Le password non vengono memorizzate. Torneremo su questo punto.

questo significa che, per impostazione predefinita, anche tutti gli altri servizi per cui usano questa password sono compromessi.

Per essere più precisi, dovrebbe essere formulata:

... questo significa che, per impostazione predefinita, tutti gli altri servizi utilizzano quell'indirizzo di posta elettronica e password dovrebbero essere considerati compromessi E se l'autore dell'attacco conosce l'altro tuo indirizzo email, dovrebbe essere considerato qualsiasi altro indirizzo che utilizzi quella password ...

Identità (per questi scopi) sono ciò che sei (indirizzo email) più ciò che conosci (password).

Se so che sei "joebob@gmail.com" su somerandomforum.com e wellsfargo.com E tu usa la stessa password per tutti e tre i dispositivi.

Ma se utilizzi "joebob@gmail.com" nei webforum e Azxdreuwa@yahoo.com per il tuo uso "personale" e "Alexander.Scott@yourowndomain.com" per uso professionale, è estremamente difficile per un attaccante algoritmico per ordinarli.

In genere con queste violazioni memorizzano la password utilizzando solo un algoritmo di hashing come SHA-1, o anche MD5 in alcuni casi recentemente

Ti conosco lo so e sono terribilmente pedante, ma generalmente non memorizziamo le password . Se è SHA-1, o MD5, o qualsiasi altro hash (incluso il povero, morto "crypt" o il più recente ininterrotto sul blocco) non c'è un viaggio di andata e ritorno affidabile dimostrabile dall'hash alla password.

NON PUOI e non puoi passare da eaf4c33ae978d3f2852021214a061534 a "Fred is dead". POTREBBE essere in grado di creare due o più stringhe di lunghezza indeterminata per lo stesso hash. Quello che puoi fare è generare stringhe finché non corrispondono. Questo è diverso ed è una differenza CRITICA. Ed è fondamentale anche per questo.

(che non sono mai stati pensati per archiviare le password in modo sicuro), rendendo facile per gli aggressori forzare le password utilizzando solo la potenza di hash della GPU.

Che perdita totale di tempo ed elettricità sarebbe MOLTO meglio spendere $ {QUALUNQUE} per l'estrazione di monete.

In ogni caso, non ricostruisci l'hash, continui a lanciare stringhe all'algoritmo finché non ottieni una corrispondenza

Le tabelle arcobaleno precalcolate sono MOLTO più veloci quando attraverso i cinque milioni di tuple email: nome: password che hai appena estratto da BigWebSiteInc, e ti daranno un MOLTO più risultati molto più velocemente.

E sì, so che le GPU possono calcolare che è molto veloce., ma le ricerche sono MOLTO più veloci e voglio rompere MOLTE password, non solo le tue.

Se voglio le TUE credenziali ho altri modi per ottenerle e se le voglio abbastanza male ... sì, probabilmente non è un forum che Stack Exchange vuole ospitare. Ci sono molti aspetti della sicurezza e la crittografia ne protegge solo alcuni.

Se una persona dovesse creare una password propriamente casuale di lunghezza sufficiente (es. 100+) di entropia molto sufficiente che viene mescolata con molti tipi di

Storia vera. Poco più di un decennio fa ero nelle riserve dell'esercito americano e loro hanno (avevano?) Un sistema in cui la tua carta d'identità militare faceva parte delle tue credenziali per il tuo account di rete. Per accedere alla maggior parte dei loro computer, dovevi inserire il tuo ID militare in un lettore di smart card e inserire il tuo "numero pin".

A un certo punto ho ricevuto una nuova carta d'identità, che necessitava di una nuova PIN. Quindi sono andato al punto di immissione del pin e ho inserito un numero di 10 cifre IIRC nella tastiera, quindi l'ho inserito di nuovo. Ha detto che il mio PIN corrispondeva e sono partito.

Sono tornato alla mia unità e ho provato ad accedere. Errore.

Così sono tornato indietro. Un paio di volte. Eravamo confusi. Poi ho accorciato il PIN e ha funzionato.

C'era un limite di 8 o 9 caratteri sul PIN (o qualsiasi altra cosa. Era $ MY_NUM-2). Il PRIMO sistema di accesso stava silenziosamente scartando i numeri extra. Il secondo no, portando a una mancata corrispondenza. (O viceversa)

ISTR ci sono alcune cose nel readme SAMBA riguardo alla prima versione del database delle password di NT che memorizza l'hash in 2 parti perché la vecchia roba di LANMAN (??) conteneva solo password di 8 caratteri. Non sono sicuro di come abbia funzionato.

Ad ogni modo, alcune delle volte il flusso di lavoro dalla schermata di immissione all'archiviazione delle password avrà un numero limitato di caratteri, altre no. E questo può cambiare quando vari siti Web cambiano il loro software. Diamine, potrebbe essere diverso su diverse parti di un sistema federato. Vuoi assicurarti di non travolgere le loro aspettative.

simboli, numeri e lettere; nel caso in cui la loro macchina non sia compromessa nel senso che ci sia un keylogger installato o simili, e tutte le loro sessioni di navigazione avvengano attraverso un tunnel crittografato, c'è il rischio nel riutilizzare questa password per più siti web se non può mai essere violati nel corso della loro vita se si verifica una violazione dei dati su uno dei servizi che utilizzano?

Onestamente, per applicazioni ad alta sicurezza (ad es. protezione delle chiavi SSH ecc.) utilizzo le prime due stanze di un paio di canzoni ben ricordate. Almeno uno di loro ha un errore di ortografia accidentale che è permanentemente fissato nella mia brana.

Il fatto è che se sto guardando un ID: pw hash in un archivio di password (file, database, qualunque cosa) VOGLIO il modo più facile da violare che posso. Non voglio il ragazzo che usa una sorta di archivio di chiavi forte e ha una password diversa per ogni altro sito, voglio solo il frutto basso. Quelli sono quelli che più probabilmente riutilizzeranno le password.

Quindi sì, rende la tua password più sicura, in un paio di cose.

Non puoi scegliere l'hash usato all'estremità e fintanto che le persone usano hash "non funzionanti" (md5, SHA-1 ecc.) puoi ottenere più di una stringa per abbinare l'hash. E finché un sito web che utilizzi continua a memorizzare le password in un hash errato, sei vulnerabile.

Questo è il motivo per cui ero pedante. Non memorizziamo le password, memorizziamo un hash della password e non ho bisogno di recuperare la TUA password, devo solo trovare una stringa che generi il stesso hash.

Può darsi che la tua stringa di 100 caratteri composta dall'output del miglior generatore di numeri casuali sbiancato accada per abbinare l'hash di "Fred is dead" e poi hai perduto.

Questo è in cima a qualcuno che mette una telecamera dove può guardarti mentre digiti, che esegue un attacco MITM alla tua sessione SSL (che è circa la metà delle principali società in cui ho lavorato negli ultimi anni - lo fanno su il loro server proxy per eseguire DLP), hackerare il sito Web per inserire del codice aggiuntivo nella loro pagina di accesso o una dozzina di altri hack.

O semplicemente mettere una pistola al ginocchio. O metodi più macabri.

Usare password usa e getta per dati usa e getta, più "identità" online e un po 'di memoria delle chiavi sufficientemente sicuro per le cose importanti è probabilmente il modo migliore per procedere. Questa è una sorta di "difesa in profondità", ed è abbastanza facile da fare (diamine, posso farlo, non può essere così difficile).

Per indirizzare qualcosa @IMSoP fa apparire un commento.

L'hash effettivamente memorizzato è solitamente la password + un hash, quindi è improbabile che il tuo forum web preferito e insicuro e la tua banca utilizzino lo stesso algoritmo di hashing e salt. Potrebbero, ma improbabile.

Tuttavia, un punto secondario è che per QUALSIASI sito che utilizza un hash non sicuro - e questo è MOLTO (vedi Un'altra storia vera di seguito) un utente malintenzionato può recuperare una stringa che hash su ciò che viene memorizzato e quindi interagisci con quel sito come te.

Questo va oltre il problema del "riutilizzo delle password", ma risolve il problema delle password super lunghe. È come in ... ehm ... altre aree della vita. Una certa quantità è buona, più è meglio, ma troppo causerà problemi.

Per quanto riguarda l'uso di hash "insicuri", le aziende tendono a preoccuparsi maggiormente delle cause legali e, in secondo luogo, della pubblicità e, infine, della sicurezza. Un mio amico ha un brevetto su un meccanismo di archiviazione abbastanza sicuro che aumenterebbe in modo significativo la sicurezza per laptop e desktop (tra le altre cose). Ha cercato di coinvolgere un paio di grandi aziende in questo, e ogni persona a cui si è rivolto ha indicato la stessa cosa: la loro sicurezza attuale soddisfa sia le "pratiche comuni del settore" che gli standard legali, quindi non sono interessati ad alcuna spesa oltre a quella . Sono, a loro avviso, "a prova di querela" e sono molto meno preoccupati per la pubblicità a causa di ciò.

Questo è il motivo per cui le banche hanno deciso che fare una domanda stupida è "autenticazione a tre fattori" e altre pratiche di sicurezza chiaramente discutibili.

Ciò significa che i loro algoritmi di hashing sono quelli forniti con il sistema operativo quando è stato installato . Perché questa è la "pratica comune del settore".

Una password di 16 o 20 caratteri memorizzata in uno strumento per password sicure è valida quanto una password di 100 caratteri in queste condizioni .

Per riassumere, non sono contrario al riutilizzo della password come alcuni qui - ho diversi computer domestici su cui condivido la stessa password (e alcuni che sono diversi), ma io mai duplicarne alcuni (account di posta elettronica personale, professionale e di lavoro, password bancarie ecc.). Non vale la pena rischiare.

In genere un sito web utilizza una funzione di hashing debole per memorizzare le password, ma sei disposto a dire che nessuno dei siti web che utilizzi memorizzerà la password utilizzando la crittografia o, peggio, in testo normale?

Riutilizzando una password, la tua sicurezza è forte quanto quella del più debole dei siti su cui la usi. Non importa quanto sia lunga o complicata la tua password se un utente malintenzionato può semplicemente leggerla dal registro di modifica della password di un server mal progettato.

Assumi un sistema perfetto con

nel caso in cui la loro macchina non sia compromessa nel senso che ci sia un keylogger installato o qualcosa di simile, e tutte le loro sessioni di navigazione vengono eseguite tramite un tunnel crittografato,

o almeno suppongo che tu lo faccia - quel tunnel crittografato sarebbe meglio essere buono.

Ma non hai alcun controllo sul server che detiene la tua password . Persino le aziende che dovrebbero saperne di più hanno recentemente rovinato il loro sistema di password: GitHub e Twitter hanno password in chiaro registrate internamente o memorizzate nella cache.

Non ci sono nemmeno vantaggio: non ricorderai mai quella password, quindi la memorizzi in un gestore di password. A quel punto puoi anche utilizzare password univoche (che sono più brevi nel caso in cui dovessi doverle riscrivere).

Puoi trovare diverse soluzioni per l'hashing delle password sui siti web: funzioni memory-hard come Argon2 o Scrypt, hardware personalizzato vulnerabile, ma almeno funzioni salate come PBKDF2, semplici funzioni hash senza sale e fattore di lavoro e - purtroppo non così raro - anche archiviazione o trasmissione di password in chiaro.

Una volta che una password è stata compromessa, potrebbe apparire negli elenchi di password utilizzati per attaccare altri siti Web. Quindi il problema con il riutilizzo della password è che la sicurezza è impostata dalla funzione più debole e se da qualche parte è presente l'archiviazione del testo in chiaro, la sicurezza è scesa a zero, anche per le password effettivamente sicure.

Esiste un rischio nel riutilizzare le password anche se la password è molto complessa. Se un sito Web che memorizza le password in chiaro viene violato, la tua password complessa sarà disponibile per gli aggressori senza la necessità di forzare gli hash. In altre parole, se utilizzi la tua password molto complessa su un sito Web che memorizza le password in testo normale, la forza della tua password non ottiene nulla.

Sfortunatamente molti siti Web memorizzano le password in chiaro e non è sempre immediatamente ovvio se un sito web lo fa o meno. Quindi non è sicuro riutilizzare una password molto complessa partendo dal presupposto che l'hash non sarà forzato, perché potrebbe comunque finire per essere archiviato (e violato) come testo in chiaro.

TL; DR : la cracking delle password non è l'unica considerazione di sicurezza con il riutilizzo della password. Condividere una password con più siti significa che se ci sono problemi con gli altri siti / il tuo computer / la tua rete a parte password violabili sei ancora a rischio.

Alcune ottime risposte già qui, ma solo per aggiungere qualche altra considerazione e un riepilogo.

La tua domanda presuppone molte affermazioni di cui la maggior parte delle persone non avrà il controllo:

la loro macchina non è compromesso nel senso che è installato un keylogger o qualcosa di simile

Non dimenticare anche la sicurezza di rete, il tuo tunnel crittografato conferma che non è MITMd? E i problemi di HTTPS, una CA compromessa? Un altro scenario in stile HEARTBLEED in cui tutto il traffico verso il sito è stato compromesso perché il certificato è stato violato? Inoltre, se ora scrivessi un keylogger, a meno che non ci sia un gran numero di infezioni, non sarai necessariamente in grado di rilevarlo. Effettui il login su altre macchine che altri hanno utilizzato? Consenti ad altre persone di utilizzare le tue macchine? E i dispositivi mobili? Aggiornate regolarmente il vostro computer? E se ti vedo digitare la password in un luogo pubblico dotato di telecamere a circuito chiuso? Registratore di tasti hardware? L'attacco di una domestica malvagia?

.. Penso che questo sia tutto un grande presupposto ...

c'è un rischio nel riutilizzare questa password per più siti web se non può mai essere violati nel corso della loro vita se si è verificata una violazione dei dati su uno dei servizi che utilizzano?

Recentemente è stato rivelato che mentre Twitter potrebbe memorizzare le password in modo sicuro, la loro funzionalità di registrazione ne perdeva. Devi anche escludere qualche altra debolezza specifica dell'implementazione in tutta l'implementazione del sito.

Lo accenni nella prefazione sui siti non sicuri, quindi presumo che tu stia anche assumendo che tutti i siti in cui utilizzerai questa password che conosci proteggano anche la password in modo sicuro. Per la maggior parte dei siti che utilizzo online come faccio a saperlo ? Non lo farò e anche se dicono di eseguire l'hash delle password in modo sicuro, non ci sono garanzie che lo facciano.

Usa password diverse per siti diversi. Usa un gestore di password, KeePass è abbastanza buono :-).

Stai assumendo che nessuno dei siti visitati sia ostile. Se mi registro su un sito e fornisco loro il mio indirizzo e-mail e utilizzo la stessa password per questo sito come faccio per il mio indirizzo e-mail, possono accedere alla mia e-mail.

Qualcosa che Mark Zuckerberg confessa di aver fatto quando avvio di Facebook.

Se una persona dovesse creare una password propriamente casuale di lunghezza sufficiente (es. 100+) di entropia molto sufficiente che è mescolata con molti tipi di simboli, numeri e lettere; nel caso in cui la loro macchina non sia compromessa nel senso che ci sia un keylogger installato o simili, e tutte le loro sessioni di navigazione avvengano attraverso un tunnel crittografato, c'è il rischio nel riutilizzare questa password per più siti web se non può mai essere violati nel corso della loro vita se si verifica una violazione dei dati su uno dei servizi che utilizzano?

Ci sono alcuni problemi con questo. Prima di tutto, le password che stai suggerendo sono troppo lunghe. Ci sono circa 2 ^ 6.6 caratteri ASCII stampabili. Una password casuale uniforme di 20 caratteri è quindi sufficiente per la sicurezza a 128 bit e 39 caratteri sono sufficienti per 256 bit. Le passphrase forti potrebbero concettualmente entrare nel territorio di oltre 100 caratteri, ma la loro forza ha poco a che fare con la quantità di simboli o lettere.

Il secondo e più grande problema è che stai riponendo una fiducia non necessaria negli implementatori del sito . Se nessuno dei siti mai ha un bug che consente a un utente malintenzionato di recuperare la password, allora sì, sarebbe sicuro riutilizzare il parola d'ordine. Il problema è che è un enorme "se". È molto facile anche per un sito Web che ha progettato un buon sistema di archiviazione delle password rivelare accidentalmente le tue password. Considera questo incidente di Twitter molto recente (dall'inizio di questo mese):

Oggi, Twitter ha inviato un avviso agli utenti chiedendo loro di cambiare le loro password dopo aver scoperto che alcuni utenti "le password erano state registrate in testo normale in un file di registro accessibile solo dai dipendenti di Twitter.

[...] Ma a causa di un bug di codifica, ha spiegato Agrawal, "le password sono state scritte in un registro interno prima di completare il processo di hashing. Abbiamo riscontrato questo errore noi stessi, rimosso le password e stiamo implementando piani per prevenire questo bug che accada di nuovo. "

Questo è un errore molto facile da fare per un programmatore; basta inserire una riga log (LogLevel.DEBUG, "loginRecord = {}", loginRecord) o simile nel programma e qualcun altro attiva inavvertitamente il log di debug in produzione. Ora moltiplicalo per migliaia di programmatori in migliaia di giorni su dozzine di siti Web e i dadi sono decisamente contro di te. Non riutilizzare le password. E utilizza un gestore di password.

Modifica l'idea originale

Tuttavia, una modifica della tua idea potrebbe essere abbastanza sicura. Supponiamo di generare 64 byte di dati casuali, quindi di salvarli in un file. Scegli quindi una "password principale" che non dirai mai a nessuno, quindi utilizza quella password, il file salvato e il nome del sito per generare una password specifica del sito:

(echo password super-segreta; cat test-rand; echo amazon.com) | md5sum | sed 's /. * $ //' | xxd -r -p | base64

La riga di comando precedente produrrà sempre la password Tj02tXSPT + cQvN + 79QqtjA == dal particolare file casuale che ho creato, ma se cambio amazon in google , produrrà invece oX9uOqM0 / wUaNzUlTMUcfg == .

Se digito la password principale in modo errato, ottengo qualcosa di completamente diverso come output, ma fintanto che lo inserisco correttamente , Ottengo sempre lo stesso output per lo stesso sito, ma un output diverso per ogni sito diverso. Ora nessuno ha il "file chiave" e la password principale (una sorta di autenticazione a due fattori) necessari per generare le password specifiche del sito. Se amazon è compromessa, la mia password google no. Le password contengono ciascuna 128 bit di casualità, che dovrebbero essere sufficienti per qualsiasi cosa.

Il riutilizzo della password è sempre una valutazione del rischio. In termini pratici, il riutilizzo della password è un dato di fatto e la domanda è dove utilizzare quale set.

Tuttavia, la vera risposta alla tua domanda è che ci sono molti modi per compromettere una password e forzare in realtà è il meno probabile. Esistono sniffer, keylogger, MitM, server compromessi, varie forme di XSS e altri attacchi web, navigazione a spalla e probabilmente una dozzina di altri modi per la tua password, e per molti di loro la complessità o la lunghezza della password non fa differenza.

Esistono molti modi in cui una password può essere compromessa. L'utilizzo di password uncrackable, nella migliore delle ipotesi, non fa nulla per mitigare il rischio di compromissione con altri mezzi. In realtà, peggiora altre debolezze.