Domanda:
"Lo schema XKCD spesso citato [...] non è più un buon consiglio"?
Nick T
2014-07-10 10:16:44 UTC
view on stackexchange narkive permalink

Stavo inciampando e mi sono imbattuto in questo saggio di Bruce Schneier che affermava che lo schema delle password XKCD era effettivamente morto.

Moderno i cracker di password combinano parole diverse dai loro dizionari: [...]

Questo è il motivo per cui lo schema XKCD spesso citato per generare password - unire parole singole come "correcthorsebatterystaple" - non è più un buon consiglio . I cracker di password stanno facendo questo trucco.

L'aggressore inserirà tutte le informazioni personali a cui ha accesso sul creatore di password nei cracker di password. Un buon cracker di password verificherà i nomi e gli indirizzi dalla rubrica, le date significative e qualsiasi altra informazione personale in suo possesso. [...] se il tuo programma lo ha mai memorizzato in memoria, questo processo lo afferrerà.

La sua tesi sembra essere tale perché è noto che le persone potrebbero costruire le proprie password in questo modo che lo rende suscettibile di attaccare, ma sembra che la forza risieda puramente nel potere degli esponenti. Presumo stia alludendo a persone che non scelgono le parole in modo veramente casuale, il che forse non è del tutto falso, dato che ho rilanciato un paio di volte per ottenere qualcosa che non sia tutto avverbi e aggettivi. Tuttavia, presumo che abbassare l'entropia di un fattore 2-10 non sia realmente significativo (se l'elenco di parole è raddoppiato a 4000, non così difficile, la perdita è più che recuperata).

un'altra battuta su "se il tuo programma l'ha mai memorizzata in memoria" è un po 'sconcertante però ... non tutte le password sono archiviate in memoria una volta o l'altra? Questo sembra un po 'esagerato; cosa sta realmente riferisce?

Una discussione con 123 commenti su questo argomento è su http://www.reddit.com/r/technology/comments/1yxgqo/bruce_schneier_on_choosing_a_secure_password/
Al passaggio del mouse, il titolo dell'immagine rivela: _ "A chiunque comprenda la teoria e la sicurezza dell'informazione e si trovi in ​​una discussione irritante con qualcuno che non lo fa (possibilmente coinvolgendo casi misti), mi scuso sinceramente." _ Questo ti aiuterebbe :)
Questo TED talk contiene alcune ricerche interessanti su diversi schemi di creazione di password, incluso quello xkcd: http://www.ted.com/talks/lorrie_faith_cranor_what_s_wrong_with_your_pa_w0rd
È mai stato un buon consiglio? Per me il problema con lo schema proposto da Randal è che ha solo 44 bit di entropia. E questo è stato molti anni dopo che i 56 bit di DES erano stati forzati. In questi giorni la forza bruta della rete bitcoin circa 66 bit ogni 10 minuti.
@kasperd Penso che poiché le password vengono sottoposte a hashing più volte (o dovrebbero esserlo), vi sia una maggiore difficoltà nel trovare una collisione (o è un'immagine preliminare, chiaramente non sono un esperto)
@NickT: Non è chiaro a cosa ti riferisci, ma in generale, più round di hashing * aumentano * la probabilità di collisioni e * riducono * la sicurezza. Se potessi eseguire l'hash un numero infinito di volte, finiresti sempre con lo stesso hash indipendentemente dalla password originale. L'algoritmo bcrypt è leggermente diverso perché reintroduce la password o il sale originale ad ogni round.
Solo per la cronaca: se la tua password era effettivamente "correcthorsebatterystaple" ora è molto meno sicura!
@Aaronaught Ogni hash di password iterato correttamente progettato include la password e il sale in ogni iterazione. Ciò rende qualsiasi maggiore probabilità di collisioni un non problema. Il vero svantaggio degli hash iterati è che rendono il server un bersaglio più facile per gli attacchi DoS.
@NickT Un hash iterato rende più difficile forzare la password. Se ripetessi 1000 volte, ciò darebbe all'incirca la stessa sicurezza aggiuntiva di altri 10 bit di entropia. Quindi i 44 bit di entropia nella password potrebbero essere molto difficili da decifrare come DES a 56 bit o anche di più. Ma anche con la sicurezza aggiuntiva delle iterazioni, non considero sufficienti 44 bit di entropia. Consiglierei di usare una password, che è abbastanza forte da non essere violata, anche se è memorizzata come un semplice hash senza sale o iterazioni.
Il suo metodo è migliore di quello precedente: passw0rd123
@kasperd: Puoi consigliare quello che vuoi; gli utenti normali non si preoccupano dei bit di entropia e useranno solo uno schema che crea password facili da ricordare - o le farà scrivere. Il meglio di entrambi i mondi è una password sicura, ma anche se ne usi uno, ci sono alcuni casi in cui è inaccessibile. A parte l'aggiunta di una o due parole aggiuntive a una frase generata da xkcd o diceware, non sono a conoscenza di alcuno schema che produca un'entropia significativamente maggiore senza portare costantemente a password dimenticate.
Immagino che si sia dimenticato di calcolare la perdita di entropia scrivendo * "WTF" * invece di * "Watch This Fail" *. ;)
Se usi una password come `correcthorsebatterystaple`, fai attenzione a non accedere a un sistema che la tronca silenziosamente! Una password come `correcth` è probabilmente più facile da indovinare di` N # y; f8eR`.
@Leo Penso davvero che il tuo commento debba essere elevato a una risposta. Il discorso cita esperti reali che hanno fatto esperimenti e hanno scoperto che la tecnica non era riuscita nel suo obiettivo principale di rendere la password più facile da ricordare. Inoltre dice che le persone che li hanno avuti hanno commesso più errori digitandoli a causa della maggiore lunghezza. Quindi, sebbene possa essere ancora sicuro come sempre, non è necessariamente pensato per essere un buon consiglio come lo era prima di questi studi. (Farei la risposta da solo, ma per qualche motivo i miei 100 punti bonus significano che sono abbastanza fidato da commentare ma non da lasciare una risposta.)
@trlkly: Hmm, lo stesso per me sembra. Serve più reputazione qui per pubblicare una risposta. Peccato, è stata una bella chiacchierata e ha affrontato molti punti che di solito vengono trascurati.
@Leo Cordiali saluti, hai 101 rappresentanti dal bonus di associazione del tuo account, più che sufficienti per pubblicare una risposta. Diamine, i commenti richiedono 50 ripetizioni e lo stai già facendo.
@Ajedi32: Anche questo è quello che pensavo, ma resta il fatto che questo sito non mi permette di rispondere a domande protette. I miei 100 punti di bonus di associazione non sembrano contare quando si tratta dei 10 punti reputazione su questo sito necessari per rispondere a questa domanda.
@Leo Davvero? Quello è strano. Tuttavia, sembra che tu abbia ragione: http://meta.stackexchange.com/q/170937/192171
@snailboat Il tuo commento sul troncamento della password è importante. Peggio ancora, se una password viene riutilizzata su sistemi diversi, che vengono troncati a lunghezze diverse.
In pratica, le passphrase non sembrano aiutare tanto quanto XKCD vorrebbe farti credere: [dl.acm.org/citation.cfm?id=2335356.2335366”(http://dl.acm.org/citation.cfm?id = 2335356,2335366)
Questo è il motivo per cui acquisti il ​​dizionario grande invece di quello piccolo. Ma non puoi essere creativo? Potresti pensare a una frase come "TheSloppyCthulhuAte10Sandviches". Devo solo ricordarmelo. Una volta che sai che stai scrivendo un errore Sandwich a causa di un videogioco popoloso che ti piace e apparentemente puoi scrivere Cthulhu, sei ben sistemato e fatto
[Puoi sempre usarlo per vedere la sicurezza della password] (https://codepen.io/programmer5000/full/zZdaoJ/)
Perché tutte le risposte sono così lunghe?La semplice risposta è no, il ragazzo ha completamente torto nel suo ragionamento, che gli aggressori conoscendo lo schema lo rendono insicuro.Il fumetto XKCD presume che lo schema sia noto;è tutta una questione di entropia.E se lo schema non è sicuro, non è per le ragioni che ha fornito.
Dieci risposte:
#1
+226
Hybrid
2014-07-10 12:33:17 UTC
view on stackexchange narkive permalink

La guerra santa

Penso che scoprirai che il modo corretto di generare password potrebbe iniziare una guerra santa in cui ogni gruppo pensa che l'altro stia commettendo errori matematici molto semplici o non capisca il punto. Se metti 10 professionisti della sicurezza informatica in una stanza e chiedi loro come inventare password valide, otterrai 11 risposte diverse.

L'incomprensione

Uno dei tanti motivi nessun consiglio coerente sulle password è tutto si riduce a una questione di modellazione delle minacce . Da cosa stai cercando di difenderti esattamente?

Ad esempio: stai cercando di proteggerti da un utente malintenzionato che ti sta prendendo di mira in modo specifico e conosce il tuo sistema per generare password? O sei solo uno dei milioni di utenti in un database trapelato? Stai difendendo dal cracking delle password basato su GPU o solo da un server web debole? Sei su un host infettato da malware [1]?

Penso che dovresti presumere che l'aggressore conosca il tuo metodo esatto per generare password e ti stia solo prendendo di mira. [2] Il fumetto xkcd assume in entrambi gli esempi che tutti i dettagli della generazione siano noti.

La matematica

La matematica nel fumetto xkcd è corretta e non cambierà.

Per le password devo digitare e ricordare che utilizzo uno script python che genera password in stile xkcd che sono veramente casuali. Ho un dizionario di 2 ^ 11 (2048) parole inglesi comuni, facili da scrivere. Potrei dare il codice sorgente completo e una copia del mio elenco di parole a un utente malintenzionato, ci saranno ancora 2 ^ 44 possibili password.

Come dice il fumetto:

1000 ipotesi / SecPlausible attacco a un servizio web remoto debole. Sì, il crack di un hash rubato è più veloce, ma non è ciò di cui dovrebbe preoccuparsi l'utente medio.

Questo rappresenta un buon equilibrio tra facile da ricordare e difficile da decifrare.

E se provassimo più potenza?

Sicuramente 2 ^ 44 va bene, ma il cracking della GPU è veloce e diventerà sempre più veloce. Hashcat potrebbe rompere un hash debole [3] di quelle dimensioni in un certo numero di giorni, non anni. Inoltre, ho centinaia di password da ricordare. Anche lo stile xkcd diventa difficile dopo un po '.

È qui che entrano in gioco i gestori di password, mi piace KeePass ma ce ne sono molti altri che sono sostanzialmente gli stessi. Quindi puoi generare solo una passphrase xkcd più lunga che puoi memorizzare (diciamo 10 parole). Quindi crei una password univoca a 128 bit veramente casuale per ogni account (esadecimale o 64 base sono buoni). 128 bit saranno abbastanza potenti per molto tempo. Se vuoi essere paranoico, ingrandisci, non è un lavoro extra generare password esadecimali a 256 bit.


[1] È qui che entra in gioco la memoria, se sei acceso un host compromesso che hai perso. Non importa se lo digiti o utilizzi un programma come KeePass per copiarlo e incollarlo se un utente malintenzionato può registrare / leggere la memoria.

[2] Piuttosto che il più debole (ma più probabile) supponendo che l'attaccante abbia appena torrentato un dizionario chiamato "Top Passw0rdz 4realz 111!".

[3] Certo dovremmo usare tutti PBKDF2, ecc ... ma molti siti sono ancora su SHA1. (e sono quelli buoni)

Ho pensato che il cracking della GPU non fosse possibile a causa dei vincoli di memoria della GPU. Quindi, se il dizionario non si adatta alla memoria della GPU, l'unica altra opzione è creare un elenco di tutte le passphrase possibili, cosa che non è possibile per frasi di 5 parole e oltre.
Le moderne GPU @Dick99999 possono avere 6 GB di memoria su una singola scheda (anche se ci vorrebbero 2 slot) e possono facilmente memorizzare un dizionario di poche migliaia di parole.
@NateKerkhofs Questo è spaventoso e sorprendente allo stesso tempo. La mia prima macchina (programmabile) aveva 1 mhz e 64 kb di ram e tu parli di 6 GB di memoria video ...
@PTwr Per essere onesti, sto parlando di una scheda da gioco di fascia alta estrema che costa mille euro e non si adatta alla maggior parte dei case dei computer standard. C'è anche una versione migliorata che costa 3000 EUR e ha 12 GB di memoria, ma richiede anche 3 slot.
@NateKerkhofs quindi ... NSA ne ha gruppi? Anche allora, il mio telefono ha duemila volte più potenza di calcolo e 8192 volte più ram del mio primo computer. Oh le possibilità! E controllo solo le e-mail su di esso ...
Mi piace molto il tuo generatore di password.
Viene da qualche parte? Sembra tutto molto familiare.
"Password veramente casuale a 128 bit ..." Veramente casuale? Non è ancora pseudocasuale?
Questa dovrebbe essere la risposta accettata se non altro per la parte della Guerra Santa.
@DLeh Puoi sempre lanciare una moneta 128 volte e usarla per generare e quindi inserire manualmente una password nello strumento di archiviazione.
@PTwr La NSA utilizza certamente enormi quantità di ASIC con hardware fisso che non possono fare altro che SHA1 (o MD5, ..) in parallelo. Se pensi che una GPU sia veloce, immagina qualcosa di più veloce di diversi ordini di grandezza con un consumo energetico piuttosto ragionevole. Prova di quanto sia facile qualcosa del genere anche per le persone normali sono tutti quei minatori di bitcoin VLSI là fuori. SHA1 con PBKDF2 è solo un cerotto lì, quello che vuoi veramente è qualcosa di simile a scrypt progettato per richiedere molte risorse.
@user973810 Solo per chiarimenti non ho scritto il generatore, lo uso e basta.
@DLeh Non ho esaminato così da vicino l'algoritmo di generazione di KeePass, probabilmente hai ragione sul fatto che sia pseudocasuale ma potresti semplicemente fare `dd if = / dev / random bs = 1 count = 16 | base64` e salvalo se vuoi veramente casuale.
@TankorSmash Immagino che tutto il lavoro creativo sia derivato, è la mia risposta ma ho preso la maggior parte delle idee da qualche altra parte. Ad esempio il bit su 10 persone e 11 risposte che ho adattato da un libro di Terry Pratchett sui Nani, e probabilmente non era originariamente per lì.
@Hybrid È la citazione "dove ogni gruppo pensa che l'altro stia commettendo un errore matematico molto semplice o non capisca il punto" che deve provenire da qualche altra parte
@TankorSmash Sì, è da http://blog.xkcd.com/2008/09/09/the-goddamn-airplane-on-the-goddamn-treadmill/ Mi sono appena adattato "ogni gruppo pensa che l'altro stia facendo una fisica molto semplice sbaglio"
O, anche meglio di 10 parole casuali, una frase significativa che è ancora difficile da indovinare. Ad esempio, "` XKCD è un webcomic su interwebz e ha circa 1337 spiegazioni! "" (Ho pensato solo a una cosa casuale, ma hai capito.)
@Doorknob Una volta scelte combinazioni significative, la maggior parte dell'entropia scompare. Non cercherò di stimare quante frasi potresti scegliere, ma questo è probabilmente più vicino a uno su un miliardo che a uno su 2 ^ 44.
Solo 11 risposte diverse? Non 12 o 20?
@JoeZ. 2 ^ 11, in realtà.
@JoeZ., Chi era, (LBJ?) Che sentendo gli economisti dire costantemente "da una parte ... ma dall'altra ...", gridò: "Qualcuno mi porti un economista con una mano sola!"
La matematica può essere corretta, ma se gli utenti non sono attenti, possono indebolire notevolmente la loro password attraverso una cattiva scelta di parole. Ad esempio, se scelgono sempre 4 parole ** sostantivo verbo aggettivo sostantivo ** (per creare una frase facilmente memorizzabile), ciò riduce notevolmente il numero di possibili soluzioni da provare (attacco di forza bruta).
@DLeh: Sono sicuro che intendesse veramente casuale rispetto a una frase, ma KeePass ha plug-in e supporto integrato per la raccolta di entropia aggiuntiva durante la generazione delle password, incluso il fatto che l'utente muova arbitrariamente il mouse o schiacci la tastiera.
@Doorknob "cosa a caso ho pensato" - questa è una contraddizione. Gli esseri umani non pensano a cose casuali, infatti gli esseri umani sono dei generatori di entropia molto poveri. L'enfasi e il presupposto è che questi sono * effettivamente * casuali, cioè NON qualcosa a cui "pensi".
TL; DR utilizza un gestore di password?
"Il fumetto xkcd presuppone in entrambi gli esempi che tutti i dettagli della generazione siano noti." Beh, più o meno. Il fumetto ha menzionato brevemente che "puoi aggiungere qualche altro bit per tenere conto del fatto che questo è solo uno dei pochi formati comuni".
_ "Uso uno script Python che genera password in stile XKCD" _ Non dimenticare che ora esiste una pletora di generatori di password in stile XKCD online. Alcuni lo fanno anche nel browser, come [xkcd.pw] (https://xkcd.pw/).
"1000 ipotesi / secondo Attacco plausibile a un servizio Web remoto debole. Sì, il crack di un hash rubato è più veloce, ma non è ciò di cui l'utente medio dovrebbe preoccuparsi."potrebbe essere corretto al momento della scrittura, ma di questi tempi penso che il cracking di hash rubati sia una preoccupazione molto valida, forse la più significativa?
@DennisJaheruddin Questa è forse una risposta piuttosto tardiva, ma penso che la cifra approssimativa sia 1 bit di entropia per carattere dell'inglese normale, suggerendo che ci sono un miliardo di frasi inglesi di 30 caratteri.
#2
+154
Tom Leek
2014-07-10 20:11:18 UTC
view on stackexchange narkive permalink

Schneier scrive questo:

Questo è il motivo per cui lo schema XKCD spesso citato per la generazione delle password - mettere insieme parole singole come "correcthorsebatterystaple" - non è più un buon consiglio. I cracker di password stanno facendo questo trucco.

ma la chiave per capire cosa sta veramente cercando è un po 'più avanti nel suo saggio:

C'è ancora uno schema che funziona. Nel 2008, ho descritto lo "schema Schneier"

quindi è tutto. Ole 'Bruce vuole affermare che il suo schema è l'Unico e Solo, il migliore, il vincitore, lo schema definitivo. Pertanto, deve dire cose denigratorie sui "concorrenti", indipendentemente dal fatto che tali affermazioni siano scientificamente fondate o meno.

In questo caso, si è sempre stato assunto che il Il metodo di generazione della password è noto all'autore dell'attacco. Questo è il punto centrale dei calcoli dell'entropia; vedi l'analisi. Il fatto che gli aggressori stiano "seguendo questo trucco" non cambia nulla (quando un attaccante conosce il metodo di generazione della password, il calcolo dell'entropia descrive esattamente la forza della password; quando l'attaccante è incompetente e non conosce il metodo di generazione della password, la forza della password è solo più alta, di un importo che è quasi impossibile quantificare).

La battuta sulle "password in memoria" è solo più incoerente divagazioni. Le password vanno necessariamente nella RAM a un certo punto, sia che le digiti o le copi e incolla da una cassaforte per password o qualcosa di simile.

La mia ipotesi è che Bruce fosse ubriaco.

Aggiornamento: a Schneier è stato chiesto specificamente di commentare la sua condanna della passphrase in un AMA di Reddit che ha avuto luogo il 2 agosto 2016. Ha continuato a sostenere il suo sistema di creazione della password come alternativa superiore alla parola casuale passphrase. Schneier ha detto che il suo schema "ti dà più entropia per carattere memorizzabile rispetto ad altri metodi", il che è vero se paragonato ai personaggi che compongono le parole. Ma questo è anche irrilevante quando un sistema si basa sulla memorizzazione di parole piuttosto che di caratteri e ti è consentito combinare un numero sufficiente di parole per generare un'adeguata "entropia" per la tua passphrase nel suo insieme.

Sì, ho pensato che i suoi commenti fossero una strana deviazione dal suo tipico buon consiglio. Il suo schema consigliato probabilmente non è male, ma non è stato sottoposto a molti test effettivi. L'approccio della passphrase è abbastanza facile da testare in confronto e penseresti che farebbe appello al crittografo che è in lui. Forse ha appena passato in rassegna le notizie sul cracking di passphrase in linguaggio naturale e non ha visto alcuna distinzione tra quelle e le passphrase di parole casuali.
Nessuno degli esempi "notevoli" di Schneier mostra traccia di parole scelte a caso. Inoltre, se a questi esercizi di hacking di successo vengono forniti codici hash sufficienti, troveranno alcune frasi ogni settimana, niente di straordinario: è in matematica. Anche se una frase di 4 parole casuali richiede in media 5 anni di indovinare, la possibilità che venga recuperata il giorno 1 è una su 3650, vedi anche la mia richiesta per il giorno 1 .
Link al post originale di Schneier?
La tua argomentazione su di lui che ha bisogno di denigrare la concorrenza fallisce, poiché subito dopo aver descritto il suo schema, dice "_Ancora meglio è usare password alfanumeriche casuali non memorizzabili (con simboli, se il sito lo consente), e un gestore di password come Password Safe per crearli e salvarli_ ".
@wfaulk Password Safe è una creazione di Bruce Schneier, quindi la sua argomentazione sulla concorrenza è ancora valida. La tua dichiarazione di errore fallisce ;-)
@AviD: Non lo sapevo assolutamente.
@TomLeek, È così facile trovare uno schema di password sicuro. Tira un dado da 62 facce X volte e usa i numeri che appaiono come password.
Penso che ciò a cui si riferisse fosse il fatto che il software di cracking di hash ha preso piede in questo trucco.Per quanto ne so, ora possono eseguire set di regole che combinano parole del dizionario e sostituiscono 1337 testi e altri algoritmi molto intelligenti che renderebbero questo metodo molto meno efficace.Immagino che tutte e quattro le parole del fumetto XKCD sarebbero in un elenco di dizionari.Non sarebbe passato molto tempo prima che si unissero e un'iterazione delle regole di sostituzione delle lettere scoprisse quali erano state alterate.Gioco finito.Contro il metodo della forza bruta standard "combina tutte le lettere" funzionerebbe bene.
Quello che ti manca, e apparentemente anche Schneier, è che non ci sono "trucchi" per "afferrare".La sicurezza di Diceware * presuppone già che l'attaccante sia a conoscenza dello schema *, infatti presume che il dizionario stesso sia noto.Non importa se l'aggressore ha il tuo dizionario esatto e il numero di parole: ci sono semplicemente troppe combinazioni da utilizzare per effettuare qualsiasi tipo di attacco riuscito prima che il sole esploda.
#3
+89
Jeffrey Goldberg
2014-07-11 03:20:39 UTC
view on stackexchange narkive permalink

[Divulgazione: lavoro per AgileBits, i creatori di 1Password]

Uno dei motivi per cui ho sostenuto uno schema simile a XKCD (prima che fosse chiamato così) in Toward Better Master Password nel 2011 è proprio perché la sua forza non si basa sul fatto che l'aggressore sappia quale schema hai utilizzato. Se posso citare me stesso

La cosa grandiosa di Diceware è che sappiamo esattamente quanto sia sicuro anche supponendo che l'attaccante conosca il sistema utilizzato. La sicurezza deriva dalla genuina casualità del lancio dei dadi. L'uso di quattro o cinque parole dovrebbe essere sufficiente contro gli attacchi plausibili nei prossimi anni data la velocità osservata dei cracker di password [contro 1Password Master Password]

Cosa XKCD Il fumetto non comunica efficacemente è che la selezione delle parole deve essere (uniformemente) casuale . Se chiedi agli umani di scegliere parole a caso, ottieni un forte pregiudizio per i nomi concreti. Tali pregiudizi possono e saranno sfruttati.

Quanta forza vuoi

In un mondo perfetto, vorremmo che la forza della nostra password sia forte quanto le chiavi con cui stiamo proteggendo esso. Dì 128 bit. Ma nonostante queste tecniche, gli umani non ci riusciranno. Quindi guardiamo realisticamente agli attacchi e a cosa possiamo far fare ai nostri piccoli cervelli.

Con l'elenco di parole Diceware originale di 7776 voci, ottieni circa 12,9 bit per parola che usi. Quindi, se vuoi almeno 64 bit per la tua password, allora cinque parole lo faranno.

Indovinare le password è più lento che indovinare le chiavi

In questa sezione arrivo a un resoconto molto approssimativo della busta stima che per un importo costante di dollari è 2 ^ 13 volte più lento testare una password rispetto a testare una chiave AES.

Nota che testare una password è molto più lento del testare una chiave. Se vengono utilizzati i tipi corretti di schemi di hashing delle password, è possibile mantenere la maggior parte degli aggressori al di sotto di 100.000 tentativi al secondo. Quindi, anche se potremmo non voler mai usare chiavi a 50 bit, usare password a 50 bit potrebbe comunque avere senso.

Se non ci limitiamo a tirare i dadi come nello schema originale di Diceware di Arnold Reinhold dal 1995, quindi possiamo utilizzare un elenco di parole più lungo. Il generatore di password complesse in 1Password per Windows utilizza un elenco di 17679 parole inglesi comprese tra 4 e 8 lettere incluse (prive di parole tabù e parole che implicano un apostrofo o trattini). Ciò fornisce circa 14 bit per parola. Quindi quattro di questi ti danno 56 bit, cinque ti danno 70.

Ancora una volta, devi prestare attenzione alle velocità di cracking. Deep Crack nel 1997 era in grado di eseguire 92 miliardi di test DES al secondo. Supponendo che un PC specializzato di fascia alta possa eseguire un milione di tentativi al secondo contro una password con hash ragionevolmente corretto potrebbe fare 1 milione di tentativi al secondo, allora le password oggi sono circa 16 bit più difficili da decifrare rispetto alle chiavi DES nel 1997.

Quindi diamo un'occhiata a questa stima di Stack Exchange per un processore dual core a 3,8 GHz: 670 milioni di chiavi al secondo. Se dovessimo ipotizzare $ 5000 in hardware, possiamo facilmente superare i 10 miliardi di chiavi al secondo. Pertanto, a un costo hardware simile, il cracking delle chiavi è ancora 2 ^ 13 volte più veloce del cracking delle password.

Obiettivi di sicurezza delle password rivisti

Lavorando sulla mia stima che è 2 ^ 13 volte più costoso testare una password con hash corretto rispetto a testare una chiave AES, dovremmo considerare una password con hash ragionevolmente ben 13 bit più forte della sua effettiva entropia rispetto al cracking. Se vogliamo ottenere 90 bit di "forza effettiva", allora dovrebbero bastare 77 bit di forza della password. Ciò si ottiene con una password Diceware di sei parole (77,5 bit) dall'elenco originale e 84,6 bit con sei parole tratte da un elenco di 17679 parole.

Non mi aspetto che la maggior parte delle persone utilizzi password che lungo. Mi aspetto che le persone useranno cose lunghe 4 o 5 parole. ma se sei veramente preoccupato che l'NSA insegua le tue password, sei parole dovrebbero essere sufficienti supponendo che tu usi uno schema di hashing delle password decente.

Solo stime molto approssimative

Non l'ho fatto spendere molto tempo a ricercare costi e benchmark. Ci sono molte cose nelle mie stime su cui cavillare. Ho tentato di essere conservatore (pessimista sullo schema che sto sostenendo). Sono stato vago anche sulle "password ben codificate". Di nuovo, sono molto conservatore riguardo all'hashing della password in 1Password. (Per il nostro nuovo formato di dati, gli aggressori sono stati tenuti a meno di 20.000 tentativi al secondo e per il nostro vecchio formato di dati hanno raggiunto 300.000 tentativi al secondo per macchine multi-GPU. Nelle mie stime qui, ho scelto 1 milione di tentativi per secondo per una "password con un hash ragionevolmente corretto".)

Qualche altra nota storica

L'idea generale per le password "simili a XKCD" risale almeno al S / Key password una tantum dei primi anni '80. Questi utilizzavano un elenco di 2048 parole da una a quattro lettere. Una password S / Key di sei parole ti ha portato a 66 bit. Non so se questa idea di utilizzare parole selezionate a caso da un elenco per una passphrase sia precedente a S / Key.

Nel 1995 Arnold Reinhold ha proposto Diceware. Non so se all'epoca fosse a conoscenza di S / Key. Diceware è stato proposto nel contesto dello sviluppo di passphrase per PGP. È stato anche prima che la maggior parte dei computer avesse generatori di numeri casuali crittograficamente appropriati. Quindi in realtà si tratta di tirare i dadi. (Anche se mi fido dei CSPRNG sulle macchine che uso, mi piace ancora "creare una nuova password").

Nel giugno 2011, ho ravvivato l'interesse per Diceware in Toward Better Master Passwords con qualche modifica aggiuntiva. Ciò ha portato ai miei 15 minuti di fama. Dopo l'uscita del fumetto XKCD, ho prodotto una edizione geek che trattava un po 'di matematica.

Nel luglio 2011, Randall Monroe aveva ripreso schemi simili a Diceware e pubblicato il suo ora famoso fumetto. Dato che non sono l'inventore dell'idea, non mi dispiace affatto essere messo in ombra dal fumetto. Infatti, come ho detto nel mio articolo di follow-up

Ciò che mi ci sono volute quasi 2000 parole per dire in termini non tecnici, Randall Monroe è stato in grado di riassumere in un fumetto. Questo mostra solo il potere della matematica ...

Ma c'è una cosa su come il fumetto è stato interpretato che mi preoccupa. È chiaro a me e alle persone che hanno già compreso lo schema che le parole devono essere scelte attraverso un processo casuale uniforme e affidabile. Scegliere parole "a caso" dalla tua testa non è un processo uniforme e affidabile .

È fantastico che tu abbia menzionato Diceware in una prospettiva storica e allo stesso tempo riconosci l'ottimo lavoro di marketing svolto da XKCD per le passphrase. Riguardo al tuo schema modificato, è spiegato da qualche parte perché parole di 3 o 2 lettere non sono incluse in quegli elenchi di parole? vedi http://blog.agilebits.com/2013/04/16/1password-hashcat-strong-master-passwords/expanded-dicelists/. È perché le parole come "off" e "line" potrebbero essere attaccate anche da 1 parola offline? Vedi i miei commenti sul post di Raestloz. L'elenco originale di Diceware contiene molte parole di 1, 2 e 3 lettere.
Ottima domanda! Il mio pensiero (forse errato) all'epoca era che volevo anche che le passphrase fossero di lunghezza minima. Volevo assicurarmi che se qualcuno avesse usato una passphrase di tre parole, la lunghezza sarebbe stata superiore a 12 caratteri.Noto che S / Key consente anche parole di 1, 2 e 3 lettere.
Ho controllato rapidamente la parola elenca il mio generatore di passphrase SimThrow e gli usi del tester. L'elenco originale di Diceware ha almeno 1400 di queste collisioni come "any" "how" e "anyhow". Ciò può degradare una frase di 4 parole a 3 parole, se non viene utilizzato alcun separatore. È un numero di collisione elevato perché l'elenco include tutte le lettere e le combinazioni di 2 lettere. Quindi sembra che tu abbia fatto la scelta giusta di non includere parole di 2 lettere. Diceware consiglia una lunghezza minima della frase di 17. Il mio generatore stima i tempi di recupero basati su parole e caratteri, per far fronte a siti che consentono solo password brevi (20).
Ho anche controllato le seguenti liste di parole. [S / Key] (http://www.faqs.org/rfcs/rfc1760.html):> 93 collisioni, [Expanded-dicelists US] (http://blog.agilebits.com/2013/04/16/ 1password-hashcat-strong-master-passwords / Expand-dicelists /):> 190 e la mia lista dei Paesi Bassi:> 750. Un modo per gestire questo è raccomandare di includere un carattere separatore tra le parole di una frase.
Attenzione, tirare i dadi non è perfettamente casuale. http://www.forbes.com/sites/davidewalt/2012/09/06/dice-chessex-gamescience-roll-randomn/ e http://www.insidescience.org/blog/2012/09/12/dice i rotoli non sono completamente casuali
Il modo migliore per utilizzare Diceware è utilizzare un elenco di parole privo di prefissi.L'originale elenco di parole diceware non era privo di prefissi, ma EFF aveva creato un [elenco di parole inglese EFF] (https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases) che è privo di prefissi.
Nello sviluppare l'elenco di parole che ora utilizziamo nella generazione di 1Password, ho cercato di renderlo privo di prefissi.ma costa davvero molte parole. C'è una soluzione molto più semplice.Insistere / incoraggiare l'uso di separatori tra le parole.
bella risposta Mi sono persino divertito ed ho estratto la Wordlist che 1pw usa dall'applicazione mac (abbastanza semplice con 7zip) e ho scritto un piccolo script PHP che posso eseguire localmente per generare parole, il che è davvero carino soprattutto considerando che l'elenco è MOLTO più lungoche diceware.ma quello che a volte mi piacerebbe è quando creare frasi per gli altri qui in Germania sarebbe un elenco di parole decente per diceware o qualsiasi altra cosa, dato che l'elenco di diceway per questo contiene troppa spazzatura che non sono nemmeno parole, o qualsiasi altra cosa
#4
+60
Mark
2014-07-10 12:11:07 UTC
view on stackexchange narkive permalink

Lo schema delle password di XKCD è più che mai valido. La sicurezza non deriva dall'essere sconosciuto, ma dal fatto che è un buon modo per generare password memorabili da un ampio spazio di ricerca. Se selezioni le parole da usare invece di generarle casualmente, però, questo vantaggio viene perso: gli esseri umani non sono bravi a essere casuali.

La parte sulla memoria è mal definita, ma è un problema: se il malware che ruba la password arriva sul tuo computer, spazzerà via tutto ciò che è simile al testo dalla RAM e dal disco rigido per utilizzarlo in un attacco diretto ai tuoi account.

+1 Non penso che la tecnica XKCD sia morta - non è "un trucco" quello su cui i cracker "stanno cercando". Puoi conoscere la tecnica a fondo, ma questo non la rende più crackabile se è abbastanza casuale.
@PiTheNumber se stai usando poche parole o un dizionario minuscolo, allora non stai applicando affatto la tecnica xkcd; ma no, anche nel fumetto xkcd è esplicitamente chiaro che NON stai perdendo il tuo vantaggio se dici a tutti "ehi, sto usando la password corretta in stile batteria di cavallo" - la quantità di veriazioni / bit di entropia è superiore a password più normali anche se il metodo è noto.
A condizione che non utilizzi anche il generatore di numeri casuali di XKCD (non collegherò, lo sanno tutti).
@PiTheNumber il concetto di "password veramente casuale di 11 lettere" è irrilevante, in quanto non è un'alternativa ragionevole alle passphrase. Le passphrase sono alternative alle password * memorizzabili * e sono esattamente deboli come descrive xkcd. Certo, se usi una password memorizzata in un gestore di password, allora le password completamente casuali si adattano, ma in quel caso essenzialmente non è la 'tua password' come in qualcosa che * tu * useresti o vedresti, ma piuttosto un 'token di chiave casuale generato automaticamente 'simile alle chiavi ssh.
@PiTheNumber Le parole non sono scelte dall'uomo, sono scelte a caso. Il dizionario da cui vengono scelte le parole è esso stesso scelto dall'uomo, ma questa è una questione diversa. Non c'è "molto probabile" - la matematica nel fumetto xkcd è corretta.
@SteveJessop, vuoi dire che la mia password "droiddroiddroiddroid" non è buona? :(
@PiTheNumber Sì, questo è il punto centrale del fumetto XKCD: fornisce un metodo per avere una password generata dal computer che è sia più sicura di una password generata principalmente dall'uomo (più entropia) che più facile da memorizzare. E Jeff ha completamente frainteso l'intera faccenda (la sua osservazione sul "tagliare l'entropia" è una stronzata totale).
#5
+15
wberry
2014-07-11 00:17:02 UTC
view on stackexchange narkive permalink

Come altri hanno detto, l'attacco descritto da Bruce Schneier è efficace quando l'utente sceglie più parole da solo, senza utilizzare uno strumento. Schneier di solito scrive a un pubblico generale, che è improbabile che cogli la differenza tra parole "casuali" auto-scelte e parole casuali scelte dal programma.

Aggiungerò che anche se usi uno script o altro strumento per scegliere a caso le parole da un dizionario, devi usare la prima sequenza che ti dà . Se decidi "Non mi piace" e lo esegui di nuovo finché non ti piace, non è più una passphrase casuale , è scelta dall'uomo.

Inoltre, anche se usi uno script, e anche se non danneggi la casualità scegliendo la tua preferita tra più sequenze, c'è ancora la possibilità che un attaccante possa sfruttare il tuo PRNG (generatore di numeri pseudo-casuali). Se l'attaccante può apprendere quando hai creato la password e quale PRNG hai utilizzato, e forse altre informazioni sul tuo PRNG come il traffico di rete che è stato prodotto utilizzando il tuo PRNG nello stesso periodo, ciò potrebbe ridurre l'entropia effettiva della tua passphrase casuale.

Forse un po 'esoterico, ma se il tuo PRNG è sfruttabile, la cifra 2 ^ 44 non sarà completamente realizzata. (E se presumi "nessuno tenterà di sfruttare il mio PRNG", perché ti interessa usare una passphrase veramente sicura?)

+1 Angolo interessante. Lo sfruttamento del PRNG è ovvio nel contesto delle chiavi di crittografia: è interessante che qui sembri essere praticamente un ripensamento. Immagino che le password tipiche siano così cattive che i PRNG si sentono sicuri al confronto. Presumibilmente, se un utente malintenzionato può rubare un elenco di password con hash, trovare pwdChangedTime o equivalente sarebbe banale? Un altro motivo per porre fine alla pratica dell'invecchiamento delle password?
Indietro veloce della busta. Se aggiorni la password entro un minuto dalla sua generazione e l'unica fonte di entropia nel tuo PRNG è l'ora di sistema, potresti cercare di ridurre le cose fino a 2 ^ 35 per una risoluzione in nanosecondi. Suona ragionevole?
Supponiamo che io rifiuti una frase perché non mi piace una parola e lo faccia 1000 volte. Poi ho ridotto il dizionario di 1000 parole. La scelta da quel dizionario ridotto è ancora casuale? Se lo è ancora, una frase di 4 parole da un dizionario Diceware di 7776 parole così ridotto fornisce ancora (7776-1000) ^ 4 = 2,1E15 / 50,9 possibilità / bit di entropia, giù da 3,7E15 / 51,7 possibilità / bit di entropia per il pieno dizionario. Non sono in grado di giudicare l'influenza del generatore casuale. Uso quello da www.random.org
@imsotiredicantsleep Non so molto su come vengono eseguiti gli attacchi PRNG, ma la mia sensazione è che abbiano più successo quando analizzano come vengono * inizializzati *. Il Mersenne Twister ha un periodo di 2 ^ 19937 - 1, quindi le uscite precedenti non aiutano molto l'attaccante. Ma se sai che è stato seminato con (ad esempio) timestamp corrente, indirizzo MAC e numero di serie della CPU e sai in che giorno è stata creata una password, potrebbe essere molto più semplice.
@Dick99999 Non credo che si tratti davvero del numero di scelte offerte che escludi nella scelta di una password. Riguarda lo * schema * di quali frasi * escluderesti *, se ti venissero presentate. Un utente malintenzionato potrebbe supporre che l'utente preferirà parole più brevi, parole più facili da digitare su una tastiera QWERTY e parole senza maiuscole o punteggiatura; questa strategia potrebbe ridurre notevolmente lo spazio delle passphrase da esplorare. Fondamentalmente, è lo stesso problema di indovinare le squadre sportive preferite, i compleanni ei nomi dei bambini.
@wberry Non credo che la matematica funzioni su questo. Supponi di rifiutare 1000 passphrase prima di trovarne una che ti piace. Quindi è una stima ragionevole che ti piaccia solo 1/1000 dello spazio possibile per la password. Supponiamo ora che un utente malintenzionato sia in grado di indovinare completamente quale 1/1000 dello spazio è il tuo preferito: ciò riduce il numero di possibilità da 2 ^ 44 a 2 ^ 34, il che è significativo ma non così tanto che una parola in più non può compensare la perdita. Inoltre, se limiti i tuoi rifiuti, anche questo non è necessario.
Un modo rapido per stimare approssimativamente la forza di una "passphrase casuale con rifiuti" è iniziare con la forza nominale in bit (supponendo che non ci siano rifiuti) e sottrarre un bit per considerare i rifiuti. Quindi, durante la generazione delle passphrase, sottrai un altro bit ogni volta che il numero di rifiuti raggiunge una potenza di 2 (cioè 1, 2, 4, 8, 16, ecc.). Oppure sottrai solo 10 bit e presumi che ti arrenderai molto prima di rifiutare 512 passphrase casuali. (Ovviamente, ciò presuppone che si ricomincia sempre da zero dopo aver rifiutato una frase, piuttosto che rifiutare singole parole mentre si genera una frase.)
#6
+11
The Spooniest
2014-07-10 22:07:36 UTC
view on stackexchange narkive permalink

Dipende. Una cosa che devi capire è che non si tratta di sicurezza per oscurità: i valori di entropia utilizzati nel fumetto presumono che l'aggressore sappia già che stai utilizzando questo metodo . Se l'attaccante non sa come stai generando la passphrase, l'entropia aumenta enormemente.

Il trucco per il metodo XKCD è che devi effettivamente utilizzare un generatore di numeri casuali e una buona parola elenco: non scegliere mai le parole da solo, nemmeno "a caso" (tra virgolette perché gli esseri umani sono davvero pessimi nel scegliere le cose a caso, motivo per cui non dovresti farlo). Diceware ha strumenti che ti aiutano a farlo e porta anche l'elemento casuale fuori dalla portata del computer usando dadi ordinari.

Contro un attacco di vasta portata, il genere di cose dove un utente malintenzionato ha ottenuto un elenco di password da un sito Web e non sa nulla delle password presenti nell'elenco: questo è più sicuro che mai. Proprio come dici tu, la sua forza deriva dalla potenza degli esponenti (e da un buon elenco di parole).

L'attacco di Schneier può funzionare, ma solo in un contesto completamente diverso. Il suo attacco presuppone che tu sia stato preso di mira specificamente da un attaccante che sa già molto su di te . All'inizio questo potrebbe non sembrare particolarmente preoccupante, perché l'attaccante determinato e stereotipato è un agente dell'intelligence dietro uno schermo, e la maggior parte di noi non deve preoccuparsi così tanto di quelli: ce ne sono solo così tanti, e ognuno può solo permettersi di prendersi cura di così tante persone. Ma in realtà è più un problema di quanto possa sembrare a prima vista, grazie all'avvento di malware sofisticati. Un'installazione di malware può permettersi di prendersi cura di te anche se l'attaccante non lo fa, e così finisci comunque per affrontare un aggressore estremamente determinato. In effetti, anche più determinato di quanto potrebbe essere un essere umano, sebbene molto meno creativo.

Il malware che raccoglie informazioni su di te darà alle parole che ti sembrano importanti una priorità molto alta nell'elenco delle parole. Lo fa perché la maggior parte delle persone sceglie da sé le parole "casuali", ma così facendo, in realtà si orienta piuttosto fortemente verso le parole che sono più importanti per loro: può ancora "sembrare" casuale, ma alcune parole hanno molte più probabilità di venire su rispetto ad altri. Per questo motivo, dare a queste parole alta priorità spesso si traduce in risultati relativamente rapidi, e questo è il "trucco" di cui parla Schneier.

Tuttavia, puoi ancora contrastare l'attacco di Schneier usando casualità . Il problema è che questo richiede disciplina: tutte le decisioni su quali parole usare nella passphrase (a parte la scelta di un buon elenco di parole) devono essere prese completamente dalle tue mani. È qui che cose come Diceware possono aiutarti.

Il tuo primo paragrafo è quasi completamente sbagliato (il che è un peccato, perché altrimenti la tua risposta è buona). Il fatto che l'attaccante sappia che stai usando il metodo xkcd non riduce significativamente l'entropia. Ciò che ridurrebbe l'entropia è se l'attaccante sapesse quali parole sceglieresti - cosa che non farà, se segui il metodo xkcd, perché dovresti prenderle a caso (non mentalmente, ma con un dado o qualcosa di simile veramente casuale).
@Gilles: Il motivo per cui l'entropia scende se l'aggressore conosce il metodo è che cambia l'intera struttura della password. Se non conosci il metodo, la "graffetta corretta della batteria del cavallo" assomiglia a 216 simboli da un alfabeto a 2 simboli: in altre parole, 216 bit. Se sai che sono quattro parole inglesi (e conosci la lista di parole di XKCD), allora sembrano 4 simboli di un alfabeto di 2048 simboli. 2048 ^ 4 è grande, ma è più piccolo di 2 ^ 216, che è quanti byte di entropia avrebbe una stringa di bit veramente casuale di quella lunghezza. Ma l'affermazione di XKCD lo spiega già: 2048 ^ 4 = 2 ^ 44.
Supporre che gli aggressori credano che le password siano stringhe di bit che seguono una distribuzione uniforme è un modello di aggressori totalmente irrealistico. Conoscere il metodo rappresenta solo una manciata di bit di entropia.
Allora perché XKCD afferma che una stringa di 27 caratteri ha solo 44 bit di entropia?
L'entropia non è definita sulle stringhe, ma sui metodi per generare stringhe. XKCD descrive un metodo per generare stringhe, che ha 44 bit di entropia. Il dominio di quel metodo contiene stringhe lunghe 27 caratteri, oltre a stringhe di altra lunghezza, ma la lunghezza delle stringhe non è interessante dal punto di vista della sicurezza, solo dal punto di vista dell'usabilità.
Quindi sembra che il mio errore fosse solo una questione di terminologia. Stavo parlando dell'entropia che sembra avere una password di lunghezza nota. Se non sai nulla di una password oltre alla sua lunghezza, una stringa di 27 caratteri sembra avere 2 ^ 216 bit di entropia. Se sai che si tratta di quattro parole inglesi casuali, selezionate da un elenco di 2048 parole e separate da spazi, allora sembra che abbia solo 2 ^ 44 bit di entropia (cioè ciò che afferma XKCD). Se conosci (o puoi indovinare correttamente) altri modelli, l'apparente entropia cambia di conseguenza. Modificherò la risposta per affermare questo.
Perché dovresti conoscere la lunghezza della password, ma non il fatto che le parole inglesi hanno più probabilità della media di apparire nelle password? Di nuovo, il tuo modello di attaccante è completamente irrealistico. Gli aggressori non dicono "hey, genererò tutte le possibili password di 27 lettere". Dicono più come "ehi, genererò tutte le password possibili in ordine decrescente di probabilità".
@Giles [In realtà sia la stringa che il metodo sono rilevanti] (http://en.wikipedia.org/wiki/Kolmogorov_complexity#Relation_to_entropy). Sostieni che il paragrafo di apertura di The Spooniest sia sbagliato, mentre fai un'argomentazione che sembra riaffermarlo. Se non sai come viene generata la password, l'entropia aumenta notevolmente: ~ 166 bit per 27 caratteri (superiore, inferiore, cifra, punteggiatura). Quello che stai dicendo è che gli aggressori possono utilizzare la conoscenza di come vengono generate le password per ridurlo. Sembra che tu stia discutendo la stessa cosa da estremi opposti. Inoltre, non conoscere la lunghezza * aumenta * l'entropia.
@imsoredicantsleep: Esattamente.
@Giles Supponiamo che l'attaccante sappia che si tratta di una passphrase di 4 parole senza separatori. Supponiamo che il dizionario utilizzato NON sia noto, invece viene utilizzato un dizionario di 100.000 parole. Ciò genera 1E20 / 66 possibilità / bit di entropia, da 8.1E13 / 46 possibilità / bit di entropia per un dizionario di 3000 parole. L'entropia sale parecchio.
@Giles 67 bit di entropia, non 66: devi arrotondare per eccesso per tenere conto della frazione extra (anche se è inferiore a 0,5). Non è niente di cui starnutire, ma è ancora molto lontano dal 216. Non sono nemmeno sicuro che potresti ottenere un buon elenco di parole così a lungo fuori dall'inglese, perché un buon elenco di parole deve essere pignolo su cose come le sottostringhe. Tuttavia, potrebbe rappresentare un'interessante sfida di programmazione.
@Spooniest: Se stai parlando di larghezza di banda di comunicazione e compressione ideale, arrotondare quel bit frazionario per eccesso. Se stai parlando di sicurezza della password, arrotondala per difetto.
@BenVoigt: Punto acquisito. Caso migliore contro caso peggiore. Errore mio.
Direi che anche per un aggressore sofisticato che non sa che è stato utilizzato il metodo XKCD, una passphrase come "correcthorsebatterystaple" non ha ancora molto più di 44 bit di entropia.Un argomento empirico per questo è il fatto che lo [zxcvbn stima della sicurezza della password] (https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html) lo pone a circa 49 bit (10 ^ 14,4 ipotesi≈ 2 ^ 48 ipotesi ≈ 49 bit).Stranamente potresti anche sostenere che il fumetto lo anticipa indirettamente ("Puoi aggiungere qualche altro bit per tenere conto del fatto che questo è solo uno dei pochi formati comuni.").
#7
+5
Dick99999
2014-07-10 12:33:10 UTC
view on stackexchange narkive permalink

La matematica della forza è abbastanza semplice se la scelta della parola è casuale: (numero di parole nel dizionario) ^ (numero di parole nella frase), supponendo che l'attaccante conosca il numero di nel dizionario. Quindi una frase di 5 parole che utilizza un dizionario Diceware 7776 noto ( dall'attaccante !): Ha 7776 ^ 5 = 2.8E19 o 64 bit di entropia.

C'è un elemento ciò non è menzionato nello schema: aggiungendo solo 1 carattere (casuale) in un punto casuale dell'intera frase, la forza aumenta di circa 10 bit, vedi Diceware, elementi opzionali.

Anche la matematica sopra non tiene conto del simbolo separatore tra le parole. Ciò può aggiungere altri 5 bit.

Il punto (o almeno uno di essi) del fumetto XKCD è che l'aggiunta di un carattere casuale in un luogo casuale aumenta la difficoltà di memorizzare la password più di quanto aumenti la difficoltà di decifrarla.
Vero per la memorizzazione in generale, non vero per una password principale di un vault, penso. Vedo "facile da digitare" come il vantaggio principale. Incontro sempre più situazioni in cui i gestori di password non possono inserire la password (app, rete ospite WifI) e devo digitarla.
@Mark: i caratteri extra casuali (o semplicemente non di dizionario) potrebbero essere gli stessi in tutte le tue password, il che significa che non le dimenticherai. Guadagnerai i bit extra di entropia almeno fino a quando molte altre tue password saranno compromesse, a quel punto la password è ancora xkcd-strength ...
@imsotiredicantsleep - Questo è un suggerimento molto interessante. Ho sempre cercato una soluzione per rendere più facile da usare questa tecnica di rinforzo. Potrebbe essere chiamata sicurezza per oscurità perché l'attaccante può beneficiare della conoscenza del carattere casuale e della posizione. Un leggero compromesso, credo tra facilità d'uso e sicurezza.
@Dick99999 assolutamente, è un compromesso. Ma fino a quando la componente costante non viene compromessa, sconfiggerà un ingenuo attacco del dizionario e rallenterà in modo significativo uno più sofisticato. Non sono d'accordo sul fatto che sia sicurezza per oscurità, perché posso dirti che sto usando la * tecnica * senza perdere l'entropia che i * valori possibili * mi danno. Il punto debole principale è che una volta che la parte costante è nota, hai * sacrificato lo spazio reale della password * che avrebbe potuto essere randomizzato.
@imsotiredicantsleep, concorda sul fatto che mi sbagliavo sulla sicurezza per parte dell'oscurità. Lo schema è molto simile a quello che promuovo per i gestori di password: per password veramente sensibili come i conti bancari, usa una (la stessa) prefisso o suffisso di 3-6 caratteri per tutti gli account. È solo memorizzato. Lo aggiungo manualmente alla parte memorizzata nel gestore all'apertura dell'account.
#8
+2
Dick99999
2014-07-10 13:32:04 UTC
view on stackexchange narkive permalink

Vorrei anche aggiungere una risposta , ma per altri motivi. Non è un buon consiglio [in generale] a causa dei vincoli di lunghezza:

  • Siti come Skype, ING, eBay e nel mio paese Binckbank e KPN limitano le password a 20 caratteri. (Quel limite di banca è 15, ma utilizzava l'autorizzazione a 2 fattori)
  • Con una lunghezza media di 4,5 caratteri / parola per un breve dizionario di 3000-8000 parole, che consente di utilizzare solo frasi di 3-4 parole.
  • Quando si utilizzano dizionari di grandi dimensioni la media può essere 6-7: solo 3 parole
  • Se il sito insiste nell'usare un simbolo e un numero nella password, sono disponibili solo 18 caratteri per la frase.

Queste lunghezze proteggono solo dagli attacchi online. Per gli attacchi offline, dipende dalla derivazione della chiave e dalla funzione di hash, dal numero di iterazioni e dall'hardware di cracking utilizzato dal sito dell'app, se una frase di 3-4 parole offre una protezione sufficiente.

I siti che limitano la lunghezza delle password sono spesso un ottimo indicatore del fatto che il loro sistema di archiviazione delle password è molto insicuro. Scappa. Tutto sommato, i requisiti di sicurezza della password tendono ad essere più dannosi che utili, IMO (sia per la sicurezza che per la memorabilità).
Aggiungere Suntrust all'elenco delle password limitate a 15 caratteri. Mi chiedo cosa sta succedendo a quell'industria ..
Posso dirti cosa sta succedendo in quel settore: durante i test, qualche tempo fa qualcuno ha sbagliato qualcosa che ha causato il fallimento di password lunghe. Probabilmente hanno reso la colonna del database troppo piccola. La banca ha deciso che era più conveniente limitare il campo. Altre banche lo hanno visto e, sapendo che le banche prendono decisioni redditizie, lo hanno copiato. * La maggior parte * degli utenti non si lamenta mai di non essere in grado di avere una password più lunga, quindi non è mai stato nel loro (apparente) interesse finanziario cambiare.
Il rovescio della medaglia, è molto più facile digitare "correttahorsebatterystaple" su uno smartphone che continuare a alternare tra minuscolo, maiuscolo, numeri e punteggiatura.
Gli account Microsoft non devono contenere più di 16 caratteri (impongono anche un minimo di 8).
I limiti di password bassi non significano solo metodi di archiviazione delle password non sicuri, ma significano che le password vengono archiviate in testo normale o crittografate (non con hash). @ Ángel Le mie password per tutti gli account relativi a Microsoft sono più lunghe di quella, quindi chiamo BS. Anni fa, prima di NTLM, le password di Windows erano limitate a 16 caratteri, iirc. Questo è antecedente a XP ed è poco rilevante.
@Zenexer Per quanto riguarda gli account Microsoft: gli account online Microsoft (live.com, Office 365, ecc.) Sono limitati a 16 caratteri (sono consentiti lettere, numeri e alcuni simboli).
"Non è un buon consiglio [in generale] ** avere ** vincoli di lunghezza" (Ecco, risolto.)
#9
+1
Raestloz
2014-07-10 13:53:56 UTC
view on stackexchange narkive permalink

No, non credo.

Il vero consiglio in quel fumetto di xkcd è quello di usare mnemonici facili da ricordare e generare la password finché riesci a ricordarli . Questi sono consigli di base sulla password ovunque e rimarranno sempre veri (anche il metodo di Schneier citato utilizza questi due fatti di base). In effetti, il fumetto fa uso di parole inglesi comuni, ma la tua implementazione non deve esserlo, né il fumetto implica che dovresti.

Ovviamente, le password più sicure sono stringhe totalmente casuali come l'aspetto di una stringa MD5, e probabilmente puoi usare un gestore di password per memorizzare tutte quelle password, ma poi quale password stai andando utilizzare per quel gestore? ¯ \ (ツ) / ¯

"Ovviamente, le password più sicure sono stringhe totalmente casuali" NO, vedi per un confronto https://en.wikipedia.org/wiki/Password_strength#Random_passwords
Diceware non genererebbe anche un mucchio di parole combinate in una sola? Qual è quello che Schneider ha cercato di decifrare?
Mi piace: offline -> offline? In tal caso, l'attaccante dovrebbe utilizzare un dizionario molto più grande. La lunghezza media delle parole in un dizionario compatibile con Diceware è troppo breve per avere questo tipo di "duplicati" nel dizionario, ma controllerò questo. Ma il tuo punto è un buon motivo per includere un carattere separatore tra le parole come uno spazio (?) O un trattino.
No, non è quello che consiglia xkcd, ti consiglio di leggerlo di nuovo - e l'analisi nella domanda pertinente qui (linkato sopra).
Ho risposto a un commento e una domanda su Diceware e non su un consiglio xkcd. In quale altro modo puoi interpretare "un mucchio di parole combinate in una"
La tua firma "¯ \ (ツ) / ¯" è un'ottima password: breve, facile da ricordare, davvero difficile da violare, difficile da rilevare come password in un registro.
@Daniel Azuelos, ... banale da aggiungere a un elenco di stringhe di uso comune ...
@imsotiredicantsleep tutto è abbastanza banale da aggiungere a un elenco di utilizzo comune. Anche stringhe casuali come supermanEyjafjalgladoslajökullbatman possono anche essere aggiunte a un elenco di utilizzo comune se l'attaccante lo sa in anticipo.
@Raestloz, ma quella stringa ** non è ** di uso comune. La firma è: è un'emoticon come la faccina sorridente. Google restituisce 121.000 risultati per una versione copia e incollata della firma, probabilmente molti di più se potessi essere disturbato a digitarla correttamente. E restituisce zero risultati per la tua stringa. Comune vs (apparentemente) unico.
Non credo che la stringa sia abbastanza comune nell'utilizzo delle password (che è ciò a cui l'attaccante sarebbe interessato). Ma comunque, un katakana è anche un carattere di password valido? Pensavo che le password accettassero esclusivamente solo ASCII?
@Raestloz Una persona che parla una lingua che non utilizza caratteri che si trovano nell'intervallo ASCII non utilizzerà una password ASCII. Pensi che tutte quelle persone nei paesi asiatici usino due tastiere, una per la digitazione quotidiana e una per le password? A differenza dei sistemi operativi di trent'anni, come DOS, tutti i sistemi operativi moderni gestiscono Unicode e altri set di caratteri / pagine, e qualsiasi sito web dovrebbe supportarli (a condizione che lo sviluppatore non codifichi il modulo utilizzando ogni volta un set di caratteri casuale o lascia che sia il browser a scegliere). Le password sono solo bit che significano qualcosa per gli esseri umani.
@phyrfox No, è abbastanza comune utilizzare password nell'intervallo ASCII in Asia. Inoltre, i metodi di immissione giapponese e cinese annullano il mascheramento dell'input, mostrando ogni carattere mentre lo digiti.
#10
+1
Adam Katz
2016-02-26 09:08:19 UTC
view on stackexchange narkive permalink

È importante avere il contesto giusto. Il fumetto xkcd confronta Tr0ub4dor&3 con una presunta entropia a 28 bit (anche se la calcolo come 34,6) con correcthorsebatterystaple e si presume 44 bit di entropia (un codice diceware di quattro parole è 51,7 bit ... ma una di quelle parole non è diceware. Usando un semplice dizionario ortografico di 100k parole, ho calcolato che sia 66,4 bit) .

Per prima cosa, rendiamolo più facile da capire. Sono disponibili 94 caratteri stampabili. Una password di un carattere ha log₂ (94) = 6.55 bit di entropia. Due caratteri hanno log₂ (94²) = 13.10 bit di entropia. È possibile dividere l'entropia finale di uno schema di password per 6,55 al fine di determinare la complessità equivalente di una password puramente casuale misurata in caratteri.

Pertanto:

  • 28 bit di entropia ≈ password di 4,3 caratteri (pessima!)
  • 44 bit di entropia ≈ password di 6,7 caratteri (anche cattiva)
  • 66,4 bit di entropia ≈ password di 10,1 caratteri (ok per il 2016)

Fidandosi dei numeri di xkcd, puoi capire perché Schneier era preoccupato. Questo sembra un po 'esagerato, poiché la maggior parte degli aggressori si arrenderà ancora dopo una decina di caratteri [citazione necessaria] : dovrebbero essere necessari alcuni anni perché un grande cluster rompa una password con hash MD5 di 10 caratteri— anche se ovviamente se un buon attaccante conosce il tuo schema, la lunghezza assoluta dei caratteri non è un problema.

La complessità totale dello schema è la più importante. Devi presumere che il caso peggiore ( che l'attaccante conosce il tuo schema esatto). È un'ottima idea assicurarsi inoltre che la password contenga più di 11 caratteri ( quando consentito), ma questa è una priorità secondaria (e viene fornita gratuitamente con le passphrase).

Crea passphrase con quattro parole più un passcode

Ecco il mio consiglio per la creazione di passpharse (con stime di entropia):

  • Crea una "frase" senza senso di 4+ parole di 4+ caratteri ciascuna (100.000⁴)
  • Nessuna di queste parole può essere collegata a te, o l'una all'altra, in alcun modo
  • Usa maiuscolo e minuscolo, spazi e almeno due simboli o segni di punteggiatura (32²)
  • Almeno una parola dovrebbe fallire il controllo ortografico (es. leetspeak, parole straniere, 64 ciascuna)
  • Includere almeno un altro "errore" (ortografia / grammatica / sintassi, entropia sconosciuta)
  • Tra due parole, aggiungi un passcode tradizionale "casuale" di 7+ caratteri (92⁷)

Questo dovrebbe essere almeno log₂ (100000 100 × 32 × 3 × 64 × 92⁵) = 112 bit di entropia (che è molto forte, ≈17 caratteri). Ho saltato le maiuscole (presumo che solo il primo carattere sia maiuscolo) e un simbolo (presumo che termini con . , ! o ? , quindi il secondo simbolo ha una complessità di 3) e ho anche ipotizzato che "casuale" non sia del tutto casuale e ho calcolato il codice come un equivalente di cinque caratteri (la stretta aderenza alla formula sopra ti darebbe 128+ bit di entropia a ≈20 caratteri).

Vale la pena ripetere questo punto finale:

Gli esseri umani sono molto cattivi nel generare casualità

Pochissimi umani- ha generato codici di accesso "casuali" anche si avvicina alla vera casualità. Ci saranno schemi nel codice relativi alla tastiera della persona, ai numeri preferiti e / o al presupposto che una certa parola oscura sia indovinabile.

Ho progettato questo schema per essere robusto contro la mancanza intrinseca di casualità delle persone; assumendo un vocabolario limitato (diciamo le 2600 parole in Inglese di base), l'uso di parole correlate (penalizzate contando solo tre parole) e un passcode limitato all'entropia di sei caratteri alfanumerici, log₂ (2600³ × 62⁶) in sé è ancora forte a 70 bit (≈10,6 caratteri).

Non lasciare che questa annacquare la tua passphrase! Questa sezione è presente per dimostrare che questo schema ha una certa resistenza alla limitata entropia delle scelte umane, non per incoraggiare scelte sbagliate.

L'unico vero problema viene dalle persone che prendono citazioni o testi come quattro parole. Queste passphrase sono banalmente sconfitte se la citazione o il testo possono essere indovinati (ad esempio guardando i tuoi Mi piace di Facebook) o altrimenti avrebbero un'entropia di circa 6 caratteri casuali in un tempo di crack da 30 secondi (MD5) a 17 giorni (PBKDF2) .

Puoi utilizzare la mia tabella di entropia per calcolare l'entropia del tuo schema di passphrase.

(Don ' Non preoccuparti del fatto che le password risiedono brevemente nella memoria a meno che tu non sia uno sviluppatore)

Va anche notato che i caratteri non [ASCII] (https://en.wikipedia.org/wiki/ASCII) sono come proiettili d'argento, che sconfiggono automaticamente la maggior parte degli attacchi. Una password di "•••••••••" (nove caratteri pallottola) è imbarazzantemente sicura (e sembra la stessa mascherata che non mascherata!) A causa della lunghezza e dell'oscurità, anche se sarebbe un'idea _orribile_ da cui dipendere solo questo fatto. Inserisci un carattere non ASCII nel tuo passcode + 4word e la tua complessità salirà alle stelle (per calcolare, usa il suo valore Unicode), anche se forse ** a scapito della portabilità ** (cosa succede se stai usando lo smartphone di un amico?)


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