Domanda:
Riutilizzo di password che potrebbero non essere mai violate
user173331
2018-05-20 14:39:38 UTC
view on stackexchange narkive permalink

Il riutilizzo delle password rappresenta un terribile rischio per gli utenti perché in caso di violazione dei dati, con le password non archiviate in modo sufficientemente sicuro, ciò significa che, per impostazione predefinita, anche tutti gli altri servizi per cui utilizzano questa password sono compromessi. In genere con queste violazioni memorizzano la password utilizzando solo un algoritmo di hashing come SHA-1, o anche MD5 in alcuni casi di recente (che non sono mai stati pensati per archiviare le password in modo sicuro), rendendo facile per gli aggressori forzare le password utilizzando solo l'hash della GPU grezzo potere.

Se una persona dovesse creare una password propriamente casuale di lunghezza sufficiente (es. 100+) di entropia molto sufficiente che si mescola 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 qualcosa di simile, e tutte le loro sessioni di navigazione avvengano attraverso un tunnel crittografato, c'è un rischio nel riutilizzare questa password per più siti web se può possibilmente non verranno mai violati nel corso della loro vita se si verifica una violazione dei dati su uno dei servizi che utilizzano?

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/77955/discussion-on-question-by-azxdreuwa-reusing-passwords-that-can-possibly-never-be).
Dodici risposte:
#1
+76
reed
2018-05-20 15:50:14 UTC
view on stackexchange narkive permalink

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.

XKCD obbligatorio https://xkcd.com/792/
"stessa password per proteggere i tuoi backup" Se hai più backup, puoi anche utilizzare password separate.Altrimenti, tutto potrebbe essere compromesso insieme e vanifica lo scopo di avere più backup, almeno dal punto di vista della sicurezza.
Vedi esempio recente: https://twitter.com/twittersupport/status/992132808192634881
@jpaugh, sì, è stato un esempio, ovviamente tutto dipende da quanto sia facile accedere a tutti i backup e se è probabile che venga rilevata un'intrusione.Se sono conservati tutti nello stesso posto, è davvero un problema.
#2
+71
Petro
2018-05-21 04:23:14 UTC
view on stackexchange narkive permalink

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 "[email protected]" su somerandomforum.com e wellsfargo.com E tu usa la stessa password per tutti e tre i dispositivi.

Ma se utilizzi "[email protected]" nei webforum e [email protected] per il tuo uso "personale" e "[email protected]" 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.

Il metodo menzionato nel penultimo paragrafo è talvolta chiamato "decrittazione del tubo di gomma".E, naturalmente, c'è un xkcd per questo: https://xkcd.com/538/
Questa è una delle risposte più facili e approfondite che ho letto qui.Non ho imparato nulla di nuovo da esso, ma sento di capire meglio le stesse informazioni.
Solo essendo pedante qui - se cerchi su Google `eaf4c33ae978d3f2852021214a061534`, ora vieni indirizzato a questa domanda per cui puoi facilmente vedere che mappa a" Fred è morto ".
`fintanto che le persone usano hash" non funzionanti "(md5, SHA-1 ecc.) puoi ottenere più di una stringa per abbinare l'hash. Vero, ma eccessivamente limitato.Una proprietà necessaria degli hash a lunghezza fissa è che più input verranno mappati su ciascun hash.La tua affermazione è vera per qualsiasi algoritmo hash a lunghezza fissa, non solo per quelli "non funzionanti".
"non memorizziamo le password" - questo non è del tutto vero, però.È più accurato dire "non dovremmo * memorizzare le password" o "i luoghi che utilizzano anche un minimo di sicurezza non memorizzano le password".Ci sono state molte volte in cui ho fatto clic su "Ho dimenticato la password" solo per consentire al servizio di inviare utilmente la mia password in chiaro al mio indirizzo e-mail.E proprio così, so che la password non è mai sicura, da nessuna parte, su nessun servizio.
@David compagno di poliziotto Fiera del riso.
@DavidRice _ "i luoghi che utilizzano anche un minimo di sicurezza non memorizzano le password" _ Non si può fare affidamento nemmeno su questo assunto.Twitter è normalmente abbastanza responsabile da utilizzare bcrypt per eseguire l'hashing delle proprie password, ma un errore nel processo di registrazione ha causato l'archiviazione di tutte quelle password in chiaro a prescindere, senza che i loro utenti sapessero che ciò era accaduto prima del loro recente e pubblico mea culpa.
Non so perché questo sia votato così tanto.Tante informazioni errate.Le tabelle arcobaleno sono inutili contro i sali, quindi gli aggressori * assolutamente * useranno le GPU per attaccare gli hash e ottenere risultati molto migliori nella maggior parte dei casi.Le violazioni degli account di posta elettronica non sono "niente", ti consentono di * reimpostare la password * su qualsiasi account utilizzando quell'e-mail, non importa quanto sia forte.La posta elettronica è la "chiave del regno" e merita una password MOLTO forte.Un indirizzo email * non * è "quello che sei", * non * è un segreto e la conoscenza di quale indirizzo va con la password di cui * non * dovrebbe essere considerata parte della sicurezza dell'account.
Continuando: le prime due strofe di una canzone popolare * non * sono una buona password.Gli aggressori hanno già usato canzoni pop, versi della Bibbia, citazioni di Wikipedia, ecc. Semplici errori di ortografia e sostituzioni di caratteri possono essere gestiti dalle regole di trasformazione.È meglio di "password123" di gran lunga (quindi buono per te) ma lo stai confrontando con una password generata casualmente di 100 caratteri.I testi delle canzoni non sono neanche lontanamente vicini a quella forza.E parli di collisioni hash che sono * irrilevanti * per la lunghezza della password, insieme ad altre cose non correlate che confondono semplicemente il problema.
Per quanto riguarda la posta elettronica come "ciò che sei", avevo il presupposto inespresso che generalmente "indirizzo email" è utilizzato come identità da molti siti web / luoghi.L'autenticazione a tre fattori è "Qualcosa che sei, qualcosa che conosci, qualcosa che hai" - che significa ID utente, password, token (molti posti sbagliano).Quindi, in questo senso, l'indirizzo email è il proxy per "Qualcosa che sei". Dove dico che la compromissione della posta elettronica non è nulla?Come indicato ho 4 account di posta elettronica (almeno) con password diverse che * NON VENGONO RIUTILIZZATE *
Inoltre non ho mai detto "canzone pop".Se usano dai 20 ai 40 caratteri di ogni canzone punk venduta negli anni '80 ... Quelli sono dei grandi database a $$.E non ho mai detto che fosse buono come una stringa di 100 caratteri.L'intero * punto * è che una stringa di 100 caratteri non ti rende sicuro e non aggiunge * molta * sicurezza su una stringa di 16-20 caratteri.Uso le canzoni per proteggere le mie chiavi .ssh o file crittografati con gpg.O Keepass.Hai bisogno di una passphrase lunga e non c'è posto per salvarla.In Keepass di solito uso una stringa diversa creata in modo casuale per ogni cosa.Ma non 100 caratteri.
#3
+18
Mark
2018-05-21 01:08:10 UTC
view on stackexchange narkive permalink

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.

La mia banca (in Germania) consente solo password di esattamente 5 cifre.Almeno l'account viene bloccato dopo tre false voci, ma questo non mi dà ancora molta fiducia nei loro sistemi IT e nelle revisioni di sicurezza che hanno superato.
Sebbene la memorizzazione di password in testo non crittografato sia diventata (per fortuna!) Insolita, quasi il 100% dei siti Web utilizza l'autenticazione in chiaro.
@el.pescado Cosa dovrebbe significare?Se la password memorizzata non è in chiaro, anche l'autenticazione stessa non può essere in chiaro.Sto fraintendendo?
Ti autentichi inviando la tua password in chiaro (si spera attraverso un canale protetto).Il server quindi legge la password, calcola l'hash di quella password e quindi confronta l'hash risultante con l'hash di riferimento memorizzato da qualche parte.In questo modo, il server per un momento è in possesso di una password in chiaro.Confronta quello ad es.Autenticazione del digest (es. Digest-MD5) e / o schemi Challenge-Response (es. CRAM-MD5)
@el.pescado Più di "un momento".Una delle cose che ha reso Heartbleed così grave è che ha esposto tali informazioni in memoria e decrittografate per periodi di tempo abbastanza lunghi da poter essere recuperate.Ma salvo nuove vulnerabilità come Heartbleed o l'utilizzo di connessioni non crittografate, l'unico modo per ottenere tali informazioni è compromettere la macchina stessa e, a quel punto, hai perso comunque.Inoltre, non sono convinto che la memorizzazione di password in testo normale sia * quella * non comune.
#4
+11
Chris H
2018-05-21 13:38:00 UTC
view on stackexchange narkive permalink

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

#5
+7
BeloumiX
2018-05-20 16:09:12 UTC
view on stackexchange narkive permalink

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.

#6
+7
Micheal Johnson
2018-05-22 01:26:31 UTC
view on stackexchange narkive permalink

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.

#7
+5
Matthew1471
2018-05-21 15:56:45 UTC
view on stackexchange narkive permalink

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

#8
+4
Mark Z
2018-05-22 07:56:14 UTC
view on stackexchange narkive permalink

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.

#9
+3
Luis Casillas
2018-05-22 02:48:04 UTC
view on stackexchange narkive permalink

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.

#10
+2
Monty Harder
2018-05-21 21:27:05 UTC
view on stackexchange narkive permalink

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.

Ma cosa succede se per qualche motivo è necessario modificare la password di un sito web?Se modifichi la password principale o il file casuale, otterrai password diverse per tutti i siti web.Quindi è un'idea molto interessante, ma non può battere la comodità di un gestore di password.
Congratulazioni, hai inventato un rudimentale gestore di password!Ora puoi iniziare ad aggiungere funzionalità e sperare di non rovinare nulla ... o semplicemente usarne una esistente.
@Ben La differenza tra questo e un gestore di password è che non deve memorizzare le password specifiche del sito.Per consentire la modifica delle password, come suggerisce Reed, sarebbe necessario tenere traccia di una sorta di contatore di incremento per sito, che sarebbe incluso con gli altri tre elementi in modo che la password per amazon.com possa essere modificata in amazon.com-2.E se devi memorizzarlo, potresti anche crittografare la password effettiva e memorizzarla invece.
#11
+2
Tom
2018-05-24 14:06:35 UTC
view on stackexchange narkive permalink

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.

#12
+1
ddyer
2018-05-21 05:35:37 UTC
view on stackexchange narkive permalink

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.



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