Is “ het vaak geciteerde XKCD-schema […] niet langer een goed advies ”?

Ik strompelde wat rond en kwam toevallig dit essay van Bruce Schneier tegen waarin hij beweerde dat de XKCD-wachtwoordschema was effectief dood.

Moderne wachtwoordcrackers combineren verschillende woorden uit hun woordenboeken : […]

Dit is waarom het vaak geciteerde XKCD-schema voor het genereren van wachtwoorden – afzonderlijke woorden aan elkaar rijgen zoals ” correcthorsebatterystaple ” – is niet langer een goed advies. De wachtwoordcrackers zijn op deze truc uit.

De aanvaller zal alle persoonlijke informatie waartoe hij toegang heeft over de wachtwoordmaker in de wachtwoordcrackers invoeren. Een goede wachtwoordcracker test namen en adressen uit het adresboek, betekenisvolle datums en alle andere persoonlijke informatie die het heeft. […] als uw programma het ooit in het geheugen heeft opgeslagen, zal dit proces het pakken.

Zijn bewering lijkt te zijn omdat het bekend is dat mensen hun wachtwoorden zo kunnen construeren dat het vatbaar is voor aanvallen, maar het lijkt erop dat de kracht puur in de kracht van exponenten ligt. Ik neem aan dat hij zinspeelt op mensen die de woorden niet echt willekeurig kiezen, wat misschien niet zo is. t totaal oneerlijk, want ik heb een paar keer herhaald om iets te krijgen dat niet alle bijwoorden en bijvoeglijke naamwoorden zijn. Ik neem echter aan dat het verlagen van de entropie met een factor 2-10 niet echt significant is (als de woordenlijst wordt verdubbeld tot 4000, niet zo moeilijk, het verlies is meer dan hersteld).

De andere grap over ” als je programma het ooit in het geheugen heeft opgeslagen ” is echter een beetje verontrustend … zijn niet alle wachtwoorden tegelijk in het geheugen opgeslagen? Dat lijkt een beetje te breed; waar verwijst hij eigenlijk naar naar?

Opmerkingen

  • Een discussie met 123 opmerkingen hierover vindt plaats op reddit.com/r/technology/comments/1yxgqo/ …
  • Bij mouse-over onthult de afbeeldingstitel – ” aan iedereen die informatie begrijpt theorie en veiligheid en is in een irritante discussie met iemand die dat niet doet (mogelijk met gemengde letters), mijn oprechte excuses. ” Dit zou je helpen:)
  • Deze TED-talk bevat interessant onderzoek naar verschillende schemas voor het maken van wachtwoorden, waaronder de xkcd-versie: ted.com/talks/…
  • Voor de duidelijkheid: als uw wachtwoord eigenlijk correcthorsebatterystaple was, werd het nu een stuk minder veilig!
  • Als je een wachtwoord zoals correcthorsebatterystaple gebruikt, zorg er dan voor dat je niet ‘ inlogt op een systeem dat het stilzwijgend afkapt! Een wachtwoord als correcth is waarschijnlijk gemakkelijker te raden dan N#y;f8eR.

Antwoord

De heilige oorlog

Ik denk dat je zult ontdekken dat de juiste manier om wachtwoorden te genereren een heilige oorlog zou kunnen beginnen waarbij elke groep denkt dat de ander bezig is een zeer eenvoudige wiskundige fouten of het missen van het punt. Als u 10 computerbeveiligingsprofessionals in een kamer krijgt en hen vraagt hoe u met goede wachtwoorden komt, krijgt u 11 verschillende antwoorden.

Het misverstand

Een van de vele redenen die er zijn geen consistent advies over wachtwoorden, het komt allemaal neer op een kwestie van bedreigingsmodellering . Waar probeert u zich precies tegen te verdedigen?

Bijvoorbeeld: probeert u zich te beschermen tegen een aanvaller die specifiek op u gericht is en uw systeem kent voor het genereren van wachtwoorden? Of bent u slechts een van de miljoenen gebruikers in een uitgelekte database? Verdedig je je tegen het kraken van wachtwoorden op basis van GPUs of gewoon tegen een zwakke webserver? Bevindt u zich op een host die is geïnfecteerd met malware [1]?

Ik denk dat u moet aannemen dat de aanvaller uw exacte methode voor het genereren van wachtwoorden kent en alleen op u is gericht. [2] De xkcd-strip gaat er in beide voorbeelden van uit dat alle details van de generatie bekend zijn.

De wiskunde

De wiskunde in de xkcd-strip is correct, en het zal niet veranderen .

Voor wachtwoorden moet ik typen en onthouden dat ik een python-script gebruik dat wachtwoorden in xkcd-stijl genereert die echt willekeurig zijn. Ik heb een woordenboek van 2 ^ 11 (2048) veelgebruikte, gemakkelijk te spellen Engelse woorden. Ik zou de volledige broncode en een kopie van mijn lijst met woorden aan een aanvaller kunnen geven, er zullen nog steeds 2 ^ 44 mogelijke wachtwoorden zijn.

Zoals de strip zegt:

1000 Guesses / Sec Plausibele aanval op een zwakke externe webservice. Ja, het kraken van een gestolen hash gaat sneller , maar het is niet waar de gemiddelde gebruiker zich zorgen over hoeft te maken.

Dat is een mooie balans tussen gemakkelijk te onthouden en moeilijk te kraken.

Wat als we meer kracht zouden proberen ?

Zeker 2 ^ 44 is oké, maar GPU-cracking is snel, en het wordt alleen maar sneller. Hashcat zou een zwakke hash [3] van die grootte in een aantal dagen kunnen kraken, niet in jaren. Bovendien heb ik honderden wachtwoorden om te onthouden. Zelfs in xkcd-stijl wordt het na een paar dagen moeilijk.

Hier komen wachtwoordmanagers om de hoek kijken, ik vind KeePass leuk, maar er zijn nog veel meer die in wezen hetzelfde zijn. Dan kun je gewoon een langere xkcd-wachtwoordzin die u kunt onthouden (zeg 10 woorden). Vervolgens maakt u een uniek 128-bits echt willekeurig wachtwoord voor elk account (hex of basis 64 zijn goed). 128-bits wordt sterk genoeg voor een lange tijd. Als je paranoïde wilt zijn, ga dan groter, het is geen extra werk om 256-bit hex-wachtwoorden te genereren.


[1] Dit is waar het geheugen Je ding komt binnen, als je op een gecompromitteerde host zit, ben je verloren. Het maakt niet uit of je het typt of een programma zoals KeePass gebruikt om het te kopiëren en te plakken als een aanvaller geheugen kan loggen / lezen.

[2] In plaats van de zwakkere (maar waarschijnlijker) aanname dat de aanvaller zojuist een woordenboek met de naam ” Top Passw0rdz 4realz 111! ” heeft getorrent.

[3] Natuurlijk zouden we allemaal PBKDF2 moeten gebruiken, enz … maar veel sites zijn nog steeds op SHA1. (En dat zijn de goede)

Reacties

  • @ Dick99999 moderne GPUs kunnen 6 GB geheugen hebben op een enkele kaart (hoewel er 2 slots nodig zijn) en kunnen gemakkelijk een woordenboek van een paar duizend woorden opslaan.
  • @NateKerkhofs Dit is eng en verbazingwekkend tegelijkertijd. Mijn eerste (programmeerbare) machine had 1 mhz en 64 kb ram en je spreekt over 6 GB videogeheugen …
  • ” 128-bits echt willekeurig wachtwoord … ” Echt willekeurig? Is het niet ‘ is het nog steeds pseudo-willekeurig?
  • Dit zou de geaccepteerd antwoord alleen al om geen andere reden dan het gedeelte van de Heilige Oorlog.
  • @Doorknob Als je eenmaal zinvolle combinaties hebt gekozen, verdwijnt de meeste entropie. Ik heb ‘ niet geprobeerd in te schatten hoeveel zinnen je zou kunnen kiezen, maar dit is waarschijnlijk dichter bij één op een miljard dan bij één op 2 ^ 44.

Antwoord

Schneier schrijft dit:

Dit is waarom het vaak aangehaalde XKCD-schema voor het genereren van wachtwoorden – individuele woorden als “correcthorsebatterystaple” aaneenrijgen – is niet langer een goed advies. De wachtwoordkrakers hebben deze truc doorgemaakt.

maar de sleutel om te begrijpen waar hij echt naar op zoek is, staat iets verderop in zijn essay:

Er is nog steeds één schema dat werkt. In 2008 beschreef het “Schneier-schema “

dus dat is het. Ole “Bruce wil beweren dat zijn plan de Enige is, het beste, de winnaar, het ultieme plan. Daarom moet hij minachtende dingen zeggen over de” concurrenten “, ongeacht of dergelijke beweringen zijn wetenschappelijk correct of niet.

In dit geval is altijd aangenomen dat de methode voor het genereren van wachtwoorden bekend is bij de aanvaller. Dat is het hele punt van entropieberekeningen ; zie de analyse . Dat aanvallers deze truc aan het volgen zijn, verandert helemaal niets (wanneer een aanvaller de methode voor het genereren van wachtwoorden kent, beschrijft de entropieberekening exact de wachtwoordsterkte; wanneer de aanvaller incompetent en kent de wachtwoordgeneratiemethode niet, de wachtwoordsterkte is alleen maar hoger, met een bedrag dat bijna onmogelijk te kwantificeren is).

De grap over “wachtwoorden in het geheugen” is gewoon meer onsamenhangend geklets. Wachtwoorden gaan op een gegeven moment noodzakelijkerwijs naar het RAM, of je ze nu typt of kopieert en plakt vanuit een wachtwoordkluis of iets dergelijks.

Ik vermoed dat Bruce dronken was.

Update : Schneier werd specifiek gevraagd om commentaar te geven op de veroordeling van zijn wachtwoordzin in een Reddit AMA die plaatsvond op 2 augustus 2016. Hij bleef pleiten voor zijn wachtwoordaanmaaksysteem als superieur alternatief voor willekeurige wachtwoordzinnen. Schneier zei dat zijn schema “je meer entropie geeft per te onthouden karakter dan andere methoden”, wat waar is in vergelijking met karakters die woorden vormen. Maar dit is ook niet relevant wanneer een systeem vertrouwt op het onthouden van woorden in plaats van karakters, en u “voldoende woorden mag combineren om een adequate” entropie “te genereren voor uw wachtwoordzin als geheel.

Opmerkingen

  • Ja, ik dacht dat zijn opmerkingen een vreemde afwijking waren van zijn typische goede advies.Zijn aanbevolen schema is waarschijnlijk niet ‘ niet slecht, maar ‘ niet is aan veel daadwerkelijke tests onderworpen. De passphrase-benadering is in vergelijking vrij eenvoudig te testen, en je ‘ zou denken dat dit de cryptograaf in hem zou aanspreken. Misschien bladerde hij gewoon door het nieuws over het kraken van wachtwoordzinnen in natuurlijke taal en zag ‘ geen onderscheid tussen deze en willekeurige wachtwoordzinnen.
  • Uw argument dat hij het kleineren van de wedstrijd mislukt, want onmiddellijk na het beschrijven van zijn plan, zegt hij ” Het is nog beter om willekeurige, niet te onthouden alfanumerieke wachtwoorden te gebruiken (met symbolen, als de site ze toelaat), en een wachtwoordbeheerder zoals Password Safe om ze te maken en op te slaan “.
  • @wfaulk Password Safe is Bruce Schneier ‘ s creatie, dus zijn argument over de wedstrijd blijft bestaan. Je faalverklaring mislukt 😉
  • @AviD: Dat wist ik totaal niet. 😳
  • Wat je ‘ mist, en blijkbaar ook Schneier, is dat er geen ” truc ” om ” te vangen op “. De beveiliging van Diceware gaat er al van uit dat de aanvaller op de hoogte is van het schema , in feite gaat het ervan uit dat het woordenboek zelf bekend is. Het maakt ‘ niet uit of de aanvaller uw exacte woordenboek en aantal woorden heeft: er zijn gewoon te veel combinaties om doorheen te gaan om een succesvolle aanval uit te voeren voordat de zon ontploft.

Answer

[Disclosure: ik werk voor AgileBits, de makers van 1Password]

Een van de redenen waarom ik in 2011 pleitte voor een XKCD-achtig schema (voordat het zo werd genoemd) in Toward Better Master Passwords , is precies omdat het zo sterk is vertrouw er niet op dat de aanvaller weet welk schema u heeft gebruikt. Als ik mezelf mag citeren

Het mooie van Diceware is dat we precies weten hoe veilig het is, zelfs als we ervan uitgaan dat de aanvaller het gebruikte systeem kent. De zekerheid komt van de echte willekeur van het gooien van de dobbelstenen. Het gebruik van vier of vijf woorden zou voldoende moeten zijn tegen de plausibele aanvallen in de komende jaren gezien de waargenomen snelheid van wachtwoordkrakers [tegen 1Password Master Password]

Wat de XKCD-strip niet effectief communiceert, is dat de selectie van woorden (uniform) willekeurig moet zijn . Als je mensen vraagt om willekeurig woorden te kiezen, krijg je een sterke voorkeur voor concrete zelfstandige naamwoorden. Dergelijke vooroordelen kunnen en zullen worden uitgebuit.

Hoeveel kracht wilt u

In een perfecte wereld zouden we willen dat de sterkte van ons wachtwoord net zo sterk is als de sleutels waarmee we beschermen het. Zeg 128 bits. Maar ondanks deze technieken zullen mensen dat niet bereiken. Laten we dus realistisch kijken naar aanvallen en wat we onze nietige hersens kunnen laten doen.

Met de originele Diceware-woordenlijst van 7776 inzendingen, je krijgt ongeveer 12,9 bits per woord dat je gebruikt. Dus als je minimaal 64 bits voor je wachtwoord wilt, dan zijn vijf woorden voldoende.

Het raden van wachtwoorden is langzamer dan het raden van sleutels

In dit gedeelte kom ik uit op een zeer ruwe terug van de envelop schatten dat het voor een constant bedrag van dollars 2 ^ 13 keer langzamer is om een wachtwoord te testen dan om een AES-sleutel te testen.

Merk op dat het testen van een wachtwoord veel langzamer is dan het testen van een sleutel. Als de juiste soorten wachtwoord-hash-schemas worden gebruikt, is het mogelijk om de meeste aanvallers onder de 100.000 keer per seconde te houden. Dus hoewel we misschien nooit 50 bit-sleutels willen gebruiken, kan het gebruik van 50 bit-wachtwoorden nog steeds zinvol zijn.

Als we ons niet beperken tot het gooien van dobbelstenen zoals in Arnold Reinholds origineel Diceware-schema uit 1995, dan kunnen we een langere lijst met woorden gebruiken. De Strong Password Generator in 1Password voor Windows gebruikt een lijst van 17679 Engelse woorden tussen de 4 en 8 letters inclusief (ontdaan van taboe-woorden en woorden met een apostrof of koppeltekens). Dit levert ongeveer 14 bits per woord op. Dus vier hiervan geven je 56 bits, vijf geven je 70.

Nogmaals, je moet wel letten op kraaksnelheden. Deep Crack kon in 1997 92 miljard DES-tests per seconde uitvoeren. Ervan uitgaande dat een geavanceerde gespecialiseerde pc een miljoen keer per seconde kan raden tegen een redelijk goed gehasht wachtwoord, 1 miljoen keer per seconde kan raden, dan zijn wachtwoorden tegenwoordig ongeveer 16 bits moeilijker te kraken dan DES-sleutels in 1997.

Laten we dus eens kijken naar deze Stack Exchange-schatting voor een dual-core 3,8 GHz-processor: 670 miljoen sleutels per seconde.Als we $ 5000 aan hardware zouden aannemen, kunnen we gemakkelijk meer dan 10 miljard sleutels per seconde overschrijden. Dus tegen vergelijkbare hardwarekosten is het kraken van sleutels nog steeds meer dan 2 ^ 13 keer sneller dan het kraken van wachtwoorden.

Herziene doelstellingen voor wachtwoordsterkte

Ik werk op basis van mijn schatting dat het 2 ^ 13 is keer duurder om een goed gehasht wachtwoord te testen dan om een AES-sleutel te testen, zouden we een redelijk goed gehasht wachtwoord moeten beschouwen als 13 bits sterker dan de feitelijke entropie met betrekking tot kraken. Als we 90 bits “effectieve sterkte” willen bereiken, dan is 77 bits wachtwoordsterkte voldoende. Dat wordt bereikt met een Diceware-wachtwoord van zes woorden (77,5 bits) uit de oorspronkelijke lijst en 84,6 bits met zes woorden uit een lijst van 17679 woorden.

Ik verwacht niet dat de meeste mensen wachtwoorden gebruiken die Ik verwacht dat mensen dingen zullen gebruiken die 4 of 5 woorden lang zijn. maar als je je echt zorgen maakt dat de NSA achter je wachtwoorden aan gaat, dan zouden zes woorden voldoende moeten zijn, ervan uitgaande dat je een fatsoenlijk wachtwoord hashing-schema gebruikt.

Alleen erg ruwe schattingen

Ik heb niet veel tijd besteed aan het onderzoeken van kosten en benchmarks. Er zijn veel dingen in mijn schattingen om mee te kibbelen. Ik heb geprobeerd conservatief te zijn (pessimistisch over het plan dat ik “bepleit). Ik” ben ook vaag geweest over “goed gehashte wachtwoorden”. Nogmaals, ik ben erg conservatief met betrekking tot het hashen van wachtwoorden in 1Password. (Voor ons nieuwe gegevensformaat zijn aanvallers beperkt tot minder dan 20.000 keer per seconde en voor ons oudere gegevensformaat hebben ze 300.000 keer per seconde voor meerdere -GPU-machines. In mijn schattingen hier, heb ik “1 miljoen keer raden per seconde gekozen voor een” redelijk goed gehasht wachtwoord “.)

Nog een paar historische opmerkingen

De algemene idee voor “XKCD-achtige” wachtwoorden gaat minstens zo ver terug als de S / Key eenmalige wachtwoorden uit het begin van de jaren tachtig. Deze gebruikten een lijst van 2048 wachtwoorden door vierletterwoorden. Een S / Key-wachtwoord van zes woorden leverde 66 bits op. Ik weet niet of dit idee om willekeurig geselecteerde woorden uit een lijst te gebruiken voor een wachtwoordzin ouder is dan S / Key.

In 1995 , Stelde Arnold Reinhold Diceware voor. Ik weet niet of hij toen op de hoogte was van S / Key. Diceware werd voorgesteld in de context van het ontwikkelen van wachtwoordzinnen voor PGP. Het was ook voordat de meeste computers cryptografisch geschikte generatoren voor willekeurige getallen hadden. Het gaat dus eigenlijk om rollende dobbelstenen. (Hoewel ik de CSPRNGs op de machines die ik gebruik vertrouw, geniet ik er nog steeds van “een nieuw wachtwoord op te rollen”).

In juni 2011 heb ik de interesse in Diceware nieuw leven ingeblazen in Op weg naar betere hoofdwachtwoorden met wat aanvullende aanpassingen. Dit resulteerde in 15 minuten roem. Nadat de XKCD-strip uitkwam, produceerde ik een geekeditie die een deel van de wiskunde doorliepen.

In juli 2011 had Randall Monroe Diceware-achtige schemas opgepikt en zijn nu beroemde strip . Omdat ik niet de uitvinder van het idee ben, vind ik het helemaal niet erg om door de strip te worden overrompeld. Inderdaad, zoals ik al zei in mijn vervolgartikel

Wat kostte me bijna 2000 woorden te zeggen in niet-technische termen, Randall Monroe kon samenvatten in een strip. Dit toont gewoon de kracht van wiskunde aan …

Maar er is één ding aan de manier waarop de strip is geïnterpreteerd dat me zorgen baart. Het is mij en mensen die het schema al begrepen duidelijk dat de woorden gekozen moeten worden via een betrouwbaar uniform willekeurig proces. Woorden “willekeurig” uit je hoofd kiezen is niet een betrouwbaar uniform proces .

Reacties

  • Geweldig dat je Diceware in een historisch perspectief noemt en tegelijkertijd de geweldige marketingopdracht erkent die XKCD deed voor wachtzinnen. Wordt er over uw aangepaste schema ergens uitgelegd waarom woorden van 3 of 2 letters niet in die woordenlijsten voorkomen? zie blog.agilebits.com/2013/04/16/… . Is het omdat de woorden ‘ uit ‘ en ‘ regel ‘ kan ook offline worden aangevallen door 1 woord? Zie mijn opmerkingen over de post van Raestloz. De originele Diceware-lijst bevat veel woorden van 1, 2 en 3 letters.
  • Uitstekende vraag! Mijn (mogelijk verkeerde) gedachte was destijds dat ik ook wilde dat wachtzinnen een minimale lengte hadden. Ik wilde er zeker van zijn dat als iemand een wachtwoordzin van drie woorden zou gebruiken, deze minimaal 12 tekens lang zou zijn. Ik merk op dat S / Key ook woorden van 1, 2 en 3 letters toestaat.
  • Ik controleerde snel de woordenlijsten die mijn SimThrow-wachtwoordzingenerator en -tester gebruikt.De originele Diceware-lijst bevat minstens 1400 van deze botsingen, zoals ‘ elke ‘ ‘ hoe ‘ en ‘ hoe dan ook ‘. Dat kan een zin van 4 woorden verlagen tot 3 woorden, als er geen scheidingsteken wordt gebruikt. Het ‘ is een hoog botsingsnummer omdat die lijst alle letters en 2 lettercombinaties bevat. Dus het lijkt erop dat u de juiste keuze hebt gemaakt om geen 2-letterwoorden op te nemen. Diceware raadt een minimale zinlengte van 17 aan. Mijn generator schat zowel de op woorden als de tekens gebaseerde hersteltijden om te kunnen werken met sites die alleen korte wachtwoorden (20) toestaan.
  • Ik heb ook de volgende woordenlijsten gecontroleerd. S / Key : > 93 botsingen, uitgebreide dicelists US : > 190 en mijn Nederlandse lijst: > 750. Een manier om hiermee om te gaan is door aan te bevelen een scheidingsteken op te nemen tussen de woorden van een zin.
  • Pas op, het gooien van dobbelstenen is niet perfect willekeurig. forbes.com/sites/davidewalt/2012/09/06/… En insidescience.org/blog/2012/09/12/…

Antwoord

Het XKCD-wachtwoordschema is nog nooit zo goed geweest. De beveiliging komt niet voort uit het feit dat het onbekend is, maar omdat het een goede manier is om gedenkwaardige wachtwoorden te genereren uit een grote zoekruimte. Als u de woorden selecteert die u wilt gebruiken in plaats van ze willekeurig te genereren, gaat dit voordeel verloren: mensen zijn niet goed in het willekeurig zijn.

Het gedeelte over geheugen is slecht vermeld, maar is een zorg: als wachtwoordstelende malware ooit op uw computer terechtkomt, zal het veeg alles tekstachtig uit het RAM en de harde schijf om te gebruiken in een gerichte aanval op uw accounts.

Reacties

  • +1 Ik don ‘ denk niet dat de XKCD-techniek dood is – hij is ‘ niet ‘ een truc ‘ dat crackers ‘ zijn doorgeschakeld naar ‘. Je kunt de techniek van binnen en van buiten kennen, maar dat geldt niet ‘ maak het niet meer kraakbaar als het ‘ willekeurig genoeg is.
  • @PiTheNumber als je ‘ als je niet genoeg woorden of een klein woordenboek gebruikt, ben je ‘ helemaal niet aan het toepassen van de xkcd-techniek; maar nee, zelfs in de xkcd-strip is het ‘ expliciet duidelijk dat je NIET je voordeel verliest als je het iedereen vertelt ” hey, ik ‘ m gebruik correcthorsebatterystaple-stijl wachtwoord ” – het aantal verificaties / entropie bits is hoger dan de meeste normale wachtwoorden, zelfs als de methode bekend is.
  • Mits u ‘ niet ook XKCD gebruikt ‘ s random number generator (ik heb ‘ t link gewonnen, iedereen weet het).
  • @PiTheNumber het concept van ‘ Echt willekeurig wachtwoord van 11 letters ‘ is niet relevant, aangezien het geen redelijk alternatief is voor wachtzinnen. Wachtzinnen zijn een alternatief voor te onthouden wachtwoorden, en die zijn precies zo zwak als xkcd beschrijft. Natuurlijk, als je een wachtwoord gebruikt dat is opgeslagen in een wachtwoordbeheerder, passen volledig willekeurige wachtwoorden, maar in dat geval is het ‘ in wezen niet ‘ uw wachtwoord ‘ zoals in iets dat u zou gebruiken of zien, maar eerder een ‘ automatisch gegenereerde willekeurige sleutel token ‘ vergelijkbaar met ssh-sleutels.
  • @PiTheNumber De woorden zijn niet door mensen gekozen, ze worden willekeurig gekozen. Het woordenboek waaruit de woorden worden gekozen, is zelf door mensen gekozen, maar dat is een andere zaak. Er is geen “meest waarschijnlijke” – de wiskunde in de xkcd-strip is correct.

Antwoord

Zoals anderen hebben gezegd, de aanval die Bruce Schneier beschrijft, is effectief wanneer de gebruiker zelf meerdere woorden kiest en geen hulpmiddel gebruikt. Schneier schrijft meestal voor een algemeen publiek, dat waarschijnlijk het verschil tussen zelfgekozen “willekeurige” woorden en door het programma gekozen willekeurige woorden niet begrijpt.

Ik zal dat toevoegen, zelfs als je een script of een ander hulpmiddel om willekeurig woorden uit een woordenboek te kiezen, je moet de eerste reeks gebruiken die je krijgt . Als je besluit: ” Ik vind die niet leuk, en voer het opnieuw uit totdat je het wel leuk vindt, het is niet langer een willekeurige wachtwoordzin , het is door mensen gekozen.

Zelfs als u een script gebruikt, en zelfs als u de willekeurigheid niet beschadigt door uw favoriet uit meerdere reeksen te kiezen, is er nog steeds de mogelijkheid dat een aanvaller uw PRNG (pseudo-willekeurige nummergenerator). Als de aanvaller kan ontdekken wanneer u het wachtwoord heeft aangemaakt, en welke PRNG u heeft gebruikt, en misschien andere informatie over uw PRNG, zoals netwerkverkeer dat rond dezelfde tijd met uw PRNG is geproduceerd, kan dat de effectieve entropie van uw willekeurige wachtwoordzin.

Misschien een beetje esoterisch, maar als uw PRNG kan worden misbruikt, zal het 2 ^ 44-cijfer niet volledig worden gerealiseerd. (En als u aanneemt dat “niemand zal proberen mijn PRNG te exploiteren”, waarom geef je er om een echt veilige wachtwoordzin te gebruiken?)

Opmerkingen

  • +1 Interessante invalshoek. Het exploiteren van de PRNG is duidelijk in de context van versleuteling sleutels – het ‘ is interessant dat het hier praktisch een bijzaak lijkt. Ik denk dat typische wachtwoorden zo slecht zijn dat PRNGs zich in vergelijking daarmee veilig voelen. Als een aanvaller een lijst met gehashte wachtwoorden kan stelen, zou het waarschijnlijk triviaal zijn om de pwdChangedTime of een equivalent te vinden? Nog een reden om een einde te maken aan de praktijk van wachtwoordveroudering?
  • Snel terug van de envelop. Als je het wachtwoord binnen een minuut na het genereren ervan bijwerkt en de enige bron van entropie in je PRNG de systeemtijd is, wil je misschien dingen terugbrengen tot 2 ^ 35 voor nanoseconde resolutie. Klinkt redelijk?
  • Stel dat ik een zin verwerp omdat ik een woord ‘ niet leuk vind en dat 1000 keer doe. Daarna heb ik het woordenboek met 1000 woorden verkleind. Is de keuze uit dat verkleinde woordenboek nog steeds willekeurig? Als dat nog steeds zo is, geeft een zin van 4 woorden uit een aldus gereduceerd 7776 woord Diceware-woordenboek nog steeds (7776-1000) ^ 4 = 2,1E15 / 50,9 mogelijkheden / entropiebits, lager dan 3,7E15 / 51,7 mogelijkheden / entropiebits voor de volledige woordenboek. Ik kan de invloed van de toevalsgenerator niet beoordelen. Ik gebruik die van www.random.org
  • @ Dick99999 Ik denk niet dat ‘ het ‘ echt is over het aantal aangeboden keuzes dat u uitsluit bij het kiezen van één wachtwoord. Het ‘ gaat over het patroon van welke zinnen je zou uitsluiten, als ze aan je werden gepresenteerd. Een aanvaller zou kunnen raden dat de gebruiker de voorkeur geeft aan kortere woorden, woorden die gemakkelijker te typen zijn op een QWERTY-toetsenbord en woorden zonder hoofdletters of interpunctie; deze strategie zou de ruimte aan wachtzinnen om te verkennen aanzienlijk kunnen verkleinen. In feite is het ‘ hetzelfde probleem als het raden van favoriete sportteams, verjaardagen en ‘ namen.
  • @wberry Ik denk niet ‘ dat de wiskunde daar uitkomt. Stel dat u 1000 wachtwoordzinnen afwijst voordat u er een vindt die u bevalt. Dan is het ‘ een redelijke schatting dat u slechts 1/1000 van de mogelijke wachtwoordruimte wilt. Stel nu dat een aanvaller volledig kan raden welke 1/1000 van de spatie jouw favoriet is – dat vermindert het aantal mogelijkheden van 2 ^ 44 naar 2 ^ 34, wat significant is, maar niet zozeer dat een extra woord ‘ t vul het verlies aan. Plus, als u uw afwijzingen beperkt, is zelfs dit niet nodig.

Antwoord

Het hangt ervan af. Een ding dat u moet begrijpen, is dat dit geen beveiliging door onduidelijkheid is: de entropiewaarden die in de strip worden gebruikt, gaan ervan uit dat de aanvaller al weet dat u “deze methode gebruikt . Als de aanvaller niet” weet hoe “u de wachtwoordzin genereert, wordt de entropie gaat enorm omhoog.

De truc van de XKCD-methode is dat je daadwerkelijk een generator voor willekeurige getallen en een goede woordenlijst moet gebruiken: kies nooit de woorden uzelf, zelfs niet “willekeurig” (tussen aanhalingstekens omdat mensen eigenlijk heel slecht zijn in het willekeurig kiezen van dingen, en daarom zou je het niet moeten doen). Diceware heeft tools om je hierbij te helpen, en haalt zelfs het willekeurige element buiten het bereik van de computer door gewone dobbelstenen te gebruiken.

Tegen een brede aanval – het soort ding waarbij een aanvaller een lijst met wachtwoorden van een website heeft en niets weet over wiens wachtwoorden in de lijst staan – is dit zo sterk als het ooit was. Zoals je zegt, zijn kracht komt van de kracht van exponenten (en een goede woordenlijst).

De aanval van Schneier kan werken, maar alleen in een geheel andere context. Bij zijn aanval wordt ervan uitgegaan dat u specifiek het doelwit bent van een aanvaller die al veel over u weet .In het begin lijkt dit misschien niet bijzonder zorgwekkend, omdat de stereotiepe vastberaden aanvaller een inlichtingenagent is achter een scherm, en de meesten van ons hoeven zich daar niet zoveel zorgen over te maken: er zijn er maar zo veel, en elk kan alleen veroorloven om voor zoveel mensen te zorgen. Maar het is eigenlijk meer een probleem dan het op het eerste gezicht lijkt, dankzij de komst van geavanceerde malware. Een malware-installatie kan het zich veroorloven om om u te geven, ook al doet de aanvaller dat niet, en u wordt dus nog steeds geconfronteerd met een uiterst vastberaden aanvaller. Zelfs vastberadener dan een mens zou kunnen zijn, hoewel veel minder creatief.

Malware die informatie over u verzamelt, geeft woorden die u belangrijk lijken een zeer hoge prioriteit in de woordenlijst. Het doet dit omdat de meeste mensen zelf de willekeurige woorden kiezen, maar door dat te doen, neigen ze eigenlijk heel sterk naar de woorden die voor hen het belangrijkst zijn: het kan nog steeds willekeurig aanvoelen, maar sommige woorden zullen veel eerder komen dan anderen. Om die reden resulteert het geven van een hoge prioriteit aan deze woorden vaak in relatief snelle treffers, en dit is de “truc” waar Schneier het over heeft.

je kunt de aanval van Schneier nog steeds dwarsbomen door echte willekeur te gebruiken . De vangst is dat dit discipline vereist: alle beslissingen over welke woorden je in je wachtwoordzin moet gebruiken (behalve het kiezen van een goed woord list) moeten volledig uit handen worden genomen. Dit is waar dingen als Diceware je kunnen helpen.

Reacties

  • @Gilles: de reden dat de entropie verdwijnt als de aanvaller weet dat de methode de hele structuur van het wachtwoord verandert. Als je de methode niet ‘ kent, dan is ” juiste paardenbatterij nietje ” ziet eruit als 216 symbolen uit een alfabet met 2 symbolen: met andere woorden, 216 bits. Als je weet dat het ‘ s vier Engelse woorden (en ken XKCD

s woordenlijst), dan ziet het eruit als 4 symbolen uit een alfabet met 2048 symbolen. 2048 ^ 4 is groot, maar ‘ is kleiner dan 2 ^ 216, dat is hoeveel bytes entropie een werkelijk willekeurige bitstring van die lengte zou hebben. Maar de bewering van XKCD ‘ verklaart dat al: 2048 ^ 4 = 2 ^ 44.

  • Ervan uitgaande dat aanvallers denken dat wachtwoorden bitstrings zijn die een uniforme verdeling volgen is een totaal onrealistisch model van aanvallers. Het kennen van de methode is slechts goed voor een handvol bits entropie.
  • Entropie wordt niet gedefinieerd op strings, maar op methoden om strings te genereren. XKCD beschrijft een methode om strings te genereren, die 44 bits entropie heeft. Het domein van die methode bevat strings die 27 tekens lang zijn, evenals strings met een andere lengte, maar de lengte van de strings is niet ‘ t interessant vanuit een beveiligingsperspectief, alleen vanuit een bruikbaarheidsperspectief.
  • Waarom zou u de lengte van het wachtwoord weten, maar niet het feit dat Engelse woorden vaker dan gemiddeld in wachtwoorden verschijnen? Nogmaals, uw aanvallermodel is volkomen onrealistisch. Aanvallers ‘ gaan niet “hey, ik ‘ zal alle mogelijke wachtwoorden van 27 letters genereren”. Ze lijken meer op “hey, I ‘ ll genereer alle mogelijke wachtwoorden in aflopende volgorde van waarschijnlijkheid”.
  • @Giles Eigenlijk zijn zowel de string als de methode relevant . U beweert dat de openingsparagraaf van The Spooniest ‘ onjuist is, terwijl u een argument aanvoert dat het lijkt te herhalen. Als je niet ‘ weet hoe het wachtwoord wordt gegenereerd, gaat de entropie enorm omhoog – ~ 166 bits voor 27 tekens (boven, onder, cijfer, interpunctie). Wat u zegt, is dat aanvallers kennis van hoe wachtwoorden worden gegenereerd, kunnen gebruiken om dit te verminderen. Het lijkt erop dat je hetzelfde argumenteert vanuit verschillende kanten. Ook het niet kennen van de lengte vergroot de entropie.
  • Antwoord

    De kracht wiskunde is vrij eenvoudig als de woordkeuze willekeurig is: (aantal woorden in woordenboek) ^ (aantal woorden in de zin), ervan uitgaande dat de aanvaller het aantal woorden in het woordenboek kent. Dus een zin van 5 woorden met een bekende ( door de aanvaller !) 7776 woorden Diceware-woordenboek: has 7776 ^ 5 = 2.8E19 of 64 bits entropie.

    Er is één item dat niet wordt vermeld in het schema: door slechts 1 (willekeurig) teken op een willekeurige plaats in de hele zin toe te voegen, neemt de sterkte met ongeveer 10 bits toe , zie Diceware, optionele dingen .

    De bovenstaande wiskunde houdt ook geen rekening met het scheidingsteken tussen de woorden. Dat kan nog eens 5 bits toevoegen.

    Reacties

    • Het punt (of tenminste één daarvan) van de XKCD-strip is dat het toevoegen van een willekeurig teken op een willekeurige plaats de moeilijkheidsgraad verhoogt van het onthouden van het wachtwoord meer dan dat het de moeilijkheid van het kraken vergroot.
    • Klopt voor onthouden in het algemeen, niet waar voor een hoofdwachtwoord van een kluis, denk ik. Ik zie ‘ gemakkelijk te typen ‘ als het belangrijkste voordeel. Ik kom steeds meer situaties tegen waarin wachtwoordbeheerders het wachtwoord niet kunnen invullen (apps, WifI-gastnetwerk) en ik ze moet typen.
    • @Mark – de extra willekeurige (of gewoon niet-woordenboek) tekens zouden hetzelfde zijn voor al uw wachtwoorden, wat betekent dat u ‘ niet zult vergeten. U ‘ zult de extra stukjes entropie verdienen totdat verschillende andere van uw wachtwoorden gecompromitteerd zijn, waarna het wachtwoord nog steeds xkcd-sterkte is …
    • @imsotiredicantsleep – Dat is een heel interessante suggestie. Altijd gezocht naar een oplossing om deze versterkingstechniek makkelijker in het gebruik te maken. Het zou door onduidelijkheid beveiliging kunnen worden genoemd, omdat de aanvaller kan profiteren van de kennis over het willekeurige karakter en de positie. Een kleine afweging vind ik tussen gebruiksgemak en veilig.
    • @ Dick99999 absoluut, het ‘ is een afweging. Maar totdat de constante component gecompromitteerd is, zal het een na ï ve woordenboekaanval verslaan, en een meer geavanceerde aanval aanzienlijk vertragen. Ik ben het er echter niet ‘ mee eens dat het ‘ veilig is door onduidelijkheid, aangezien ik je kan vertellen dat ik de techniek gebruik zonder de entropie te verliezen die de mogelijke waarden me geven. De belangrijkste zwakte is dat als het constante deel eenmaal bekend is, je wachtwoordvastgoed hebt opgeofferd dat willekeurig had kunnen worden ingedeeld.

    Antwoord

    Ik “zou ook graag een ja antwoord willen toevoegen, maar voor andere redenen. Het is [in het algemeen] geen goed advies vanwege de beperkte lengte:

    • Sites zoals Skype, ING, eBay en in mijn land Binckbank en KPN beperken wachtwoorden tot 20 tekens. (Die banklimiet is 15, maar er werd gebruikgemaakt van autorisatie met twee factoren)
    • Met een gemiddelde lengte van 4,5 tekens / woord voor een kort woordenboek van 3000-8000 woorden, waarmee alleen zinnen van 3-4 woorden kunnen worden gebruikt.
    • Bij het gebruik van grote woordenboeken kan het gemiddelde 6-7: 3 woorden zijn
    • Als de site erop staat een symbool en een cijfer in het wachtwoord te gebruiken, zijn er slechts 18 tekens beschikbaar voor de zin.

    Die lengtes beschermen alleen tegen online aanvallen. Voor offline aanvallen is het afhankelijk van de sleutelafleiding en hash-functie, het aantal iteraties en het kraken van hardware die door de site van de app wordt gebruikt, of een zin van 3-4 woorden voldoende bescherming biedt.

    Reacties

    • Sites die de lengte van wachtwoorden beperken, zijn vaak een goede indicator dat hun wachtwoordopslagsysteem erg onveilig is. Ren weg. Al met al zijn de vereisten voor wachtwoordsterkte eerder schadelijk dan nuttig, IMO (zowel wat betreft veiligheid als onthoudbaarheid).
    • Voeg Suntrust toe aan de lijst met wachtwoorden die beperkt is tot 15 tekens. Ik vraag me af wat er met die branche aan de hand is.
    • Aan de andere kant is het ‘ aanzienlijk eenvoudiger om ‘ correcthorsebatterystaple ‘ op een smartphone en blijf schakelen tussen kleine letters, hoofdletters, cijfers en interpunctie.
    • Lage wachtwoordlimieten don ‘ t betekent gewoon onveilige methoden voor wachtwoordopslag – ze betekenen dat wachtwoorden worden opgeslagen in platte tekst of gecodeerd zijn (niet gehasht). @ Á ngel Mijn wachtwoorden voor alle Microsoft-gerelateerde accounts zijn langer dan dat, dus ik bel BS. Eeuwen geleden, vóór NTLM, waren Windows-wachtwoorden beperkt tot 16 tekens, iirc. Dat dateert van vóór XP en is nauwelijks relevant.
    • @Zenexer Betreffende de Microsoft-accounts: Microsoft online-accounts (live.com, Office 365, etc.) zijn beperkt tot 16 tekens (letters, cijfers en sommige symbolen zijn toegestaan ).

    Antwoord

    Het is belangrijk om de juiste context te hebben. De xkcd comic vergelijkt Tr0ub4dor&3 met een veronderstelde 28-bits entropie (hoewel ik bereken het als 34.6) naar correcthorsebatterystaple en de veronderstelde 44 bits entropie (een code van vier woorden diceware is 51,7 bits … Maar een van die woorden is geen diceware. Met behulp van een eenvoudig 100k-woord spellingswoordenboek bereken ik dat het 66,4 bits is).

    Laten we dit eerst gemakkelijker te begrijpen maken. Er zijn 94 afdrukbare tekens. Een wachtwoord van één teken heeft log₂(94) = 6.55 bits entropie. Twee tekens hebben log₂(94²) = 13.10 bits entropie.U kunt de laatste entropie van een wachtwoordschema delen door 6,55 om de equivalente complexiteit van een puur willekeurig wachtwoord te bepalen, gemeten in tekens.

    Daarom:

    • 28 bits van entropie ≈ wachtwoord van 4,3 tekens (zeer slecht!)
    • 44 bits entropie ≈ wachtwoord van 6,7 tekens (ook slecht)
    • 66,4 bits entropie ≈ wachtwoord van 10,1 tekens (oké voor 2016)

    Vertrouwend op de nummers van xkcd, kun je zien waarom Schneier zich zorgen maakte. Dit lijkt een beetje overdreven, aangezien de meeste aanvallers het nog steeds opgeven na een tiental tekens [citaat nodig] —het zou een paar jaar moeten duren voordat een groot cluster een 10-karig MD5-gehasht wachtwoord heeft gebroken — hoewel het duidelijk is dat als een goede aanvaller je plan kent, de absolute tekenlengte geen probleem is.

    De totale complexiteit van het schema is het belangrijkst. Je moet ervan uitgaan dat het ergste geval is (dat de aanvaller je exacte schema kent) . Het is een goed idee om er bovendien voor te zorgen dat uw wachtwoord meer dan 11 tekens lang is ( indien toegestaan ), maar dat is een secundaire prioriteit (en het wordt gratis geleverd met wachtwoordzinnen ).

     

    Maak wachtwoordzinnen met vier woorden plus een wachtwoord

    Hier is mijn advies voor het maken van een wachtwoord (met entropieschattingen):

    • Maak een onzinnige “zin” van 4+ woorden van elk 4+ tekens (100.000⁴)
    • Geen van deze woorden kan worden gekoppeld aan jullie –of elkaar– op wat voor manier dan ook
    • Gebruik hoofdletters, spaties en ten minste twee symbolen of leestekens (32²)
    • Ten minste één woord de spellingcontrole mislukt (bijv. leetspeak, vreemde woorden, elk 64)
    • Neem ten minste één andere “fout” op (spelling / grammatica / syntaxis, entropie onbekend)
    • Tussen twee woorden, voeg een traditionele “willekeurige” toegangscode van 7+ tekens toe (92⁷).

    Dit moet ten minste log₂(100000⁴ × 32 × 3 × 64 × 92⁵) = 112 bits entropie zijn (wat erg sterk is, ≈17 tekens). Ik heb hoofdletters overgeslagen (ik neem aan dat alleen het eerste teken een hoofdletter is) en één symbool (ik neem aan dat het eindigt op ., ! of ?, dus het tweede symbool heeft een complexiteit van 3) en ik nam ook aan dat “willekeurig” niet helemaal willekeurig is en berekende de code als een equivalent van vijf tekens (strikte naleving van het bovenstaande formule zou je 128+ bits entropie geven bij ≈20 tekens).

     

    Dat laatste punt is voor herhaling vatbaar:

    Mensen zijn erg slecht in het genereren van willekeur

    Zeer weinig door mensen gegenereerde wachtwoordcodes voor “willekeurige” tekens, zelfs benaderen echte willekeur. Er zullen patronen in de code zijn gerelateerd naar het toetsenbord van de persoon, favoriete nummers en / of een aanname dat een bepaald obscuur woord niet te raden is.

    Ik heb dit schema ontworpen om robuust te zijn tegen het inherente gebrek aan willekeur van mensen; uitgaande van een beperkt vocabulaire (zeg de 2600 woorden in Basi c Engels ), gebruik van verwante woorden (bestraft door slechts drie woorden te tellen) en een toegangscode die beperkt is tot alleen de entropie van zes alfanumerieke tekens, log₂(2600³ × 62⁶) zelf is nog steeds sterk in 70 bits (≈10,6 tekens).

    Laat dit uw wachtwoordzin niet verwateren! Deze sectie is aanwezig om aan te tonen dat dit schema enige weerstand heeft tegen de beperkte entropie van menselijke keuzes, niet om slechte keuzes aan te moedigen.

    Het enige echte probleem komt van mensen die citaten of songteksten als hun vier woorden beschouwen. Deze wachtwoordzinnen worden triviaal omzeild als het citaat of de tekst kan worden geraden (bijvoorbeeld door naar je Facebook-likes te kijken) of anders een entropie zou hebben van ongeveer 6 willekeurige tekens bij een crack-tijd van 30 seconden (MD5) tot 17 dagen (PBKDF2) .

     

    U kunt mijn entropietabel gebruiken om bereken de entropie van uw wachtwoordzinenschema.

    (Maak u geen zorgen over het feit dat wachtwoorden kort in het geheugen leven tenzij je “bent een ontwikkelaar)

    Reacties

    • Er moet ook worden opgemerkt dat niet- ASCII -tekens zijn als zilveren kogels en verslaan de meeste aanvallen automatisch. Een wachtwoord van ••••••••• (negen opsommingstekens) is beschamend veilig (en ziet er hetzelfde uit als ongemaskeerd!) Vanwege de lengte en onduidelijkheid, hoewel het ‘ zou een vreselijk idee zijn om eigenlijk alleen op dit feit te vertrouwen. Plaats een niet-ASCII-teken in uw wachtwoord + 4-woord en uw complexiteit schiet omhoog (gebruik de unicode-waarde om te berekenen), hoewel misschien ten koste gaat van de draagbaarheid (wat als u ‘ gebruikt een vriend ‘ s smartphone?)

    Antwoord

    Nee, ik denk het niet.

    Het eigenlijke advies in die xkcd-strip is om geheugensteuntjes te gebruiken die u gemakkelijk kunt onthouden en genereer een wachtwoord zolang u ze kunt onthouden . Dit zijn overal basisadviezen voor wachtwoorden en zullen altijd waar zijn (zelfs de geciteerde methode van Schneier gebruikt deze twee basisfeiten). Inderdaad, de strip maakt gebruik van gewone Engelse woorden, maar uw implementatie hoeft dat niet te zijn, en dat hoeft ook niet de strip houdt in dat je dat zou moeten doen.

    Natuurlijk zijn de veiligste wachtwoorden volledig willekeurige tekenreeksen, zoals hoe een MD5-tekenreeks eruitziet, en je kunt waarschijnlijk een wachtwoordbeheerder gebruiken om al die wachtwoorden op te slaan, maar dan welk wachtwoord ga je gebruiken voor die manager? ¯ \ (ツ) / ¯

    Reacties

    • ” Natuurlijk zijn de veiligste wachtwoorden volledig willekeurige strings ” NEE, zie voor een vergelijking en.wikipedia.org/wiki/Password_strength#Random_passwords
    • Nee, dat ‘ is niet wat de xkcd adviseert, ik stel voor dat je het nogmaals leest – en de analyse in de relevante vraag hier (hierboven gelinkt).
    • Je handtekening ” ¯ \ (ツ) / ¯ ” is een uitstekend wachtwoord: kort, eenvoudig om te onthouden, echt moeilijk te breken, moeilijk te detecteren als een wachtwoord op een logboek.
    • @Daniel Azuelos, … triviaal om toe te voegen aan een lijst met veelgebruikte strings …
    • @Raestloz Een persoon die een taal spreekt die niet ‘ t gebruik geen tekens die in het ASCII-bereik liggen is niet ‘ t ga je een ASCII-wachtwoord gebruiken. Denk je dat al die mensen in Aziatische landen twee toetsenborden gebruiken, een voor alledaags typen en een voor wachtwoorden? In tegenstelling tot dertig jaar oude besturingssystemen, zoals DOS, verwerken alle moderne besturingssystemen ‘ s Unicode en andere tekensets / paginas prima, en elke website zou ze moeten ondersteunen (zolang de ontwikkelaar ‘ codeert het formulier niet elke keer met een willekeurige tekenset, of laat de browser kiezen). Wachtwoorden zijn slechts stukjes die iets voor mensen betekenen.

    Geef een reactie

    Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *