Det heliga kriget

Jag tror att du kommer att upptäcka att rätt sätt att generera lösenord kan starta ett heligt krig där varje grupp tror att den andra gör ett mycket enkelt matematiskt misstag eller saknar poäng. Om du får 10 datorsäkerhetspersonal i ett rum och frågar dem hur man kan komma med bra lösenord får du 11 olika svar.

Misförståelsen

En av de många anledningarna till att det finns inga konsekventa råd om lösenord är allt kommer till en fråga om hotmodellering . Vad försöker du verkligen försvara dig mot?

Till exempel: försöker du skydda dig mot en angripare som specifikt riktar sig mot dig och känner till ditt system för att generera lösenord? Eller är du bara en av miljoner användare i någon läckt databas? Försvarar du mot GPU-baserad lösenordssprickning eller bara en svag webbserver? Är du på en värd som är infekterad med skadlig kod [1]?

Jag tror att du borde anta att angriparen känner till din exakta metod för att generera lösenord och bara riktar in dig. [2] Xkcd-serien antar i båda exemplen att alla detaljer i generationen är kända.

Matematiken

Matematiken i xkcd-serien är korrekt och den kommer inte att förändras .

För lösenord måste jag skriva och komma ihåg att jag använder ett python-skript som genererar lösenord för xkcd-stil som är riktigt slumpmässiga. ordbok med 2 ^ 11 (2048) vanliga, enkla att stava, engelska ord. Jag skulle kunna ge hela källkoden och en kopia av min ordlista till en angripare, det kommer fortfarande att finnas 2 ^ 44 möjliga lösenord.

Som serietecknet säger:

1000 Gissningar / Sec Plausibla attacker på en svag fjärrwebbtjänst. Ja, att knäcka en stulen hash är snabbare , men det är inte vad den genomsnittliga användaren bör oroa sig för.

Det är en fin balans mellan lätt att komma ihåg och svårt att knäcka.

Vad händer om vi försökte mer kraft ?

Visst 2 ^ 44 är ok, men GPU-krackning går snabbt och det blir bara snabbare. Hashcat kan knäcka en svag hash [3] av den storleken på ett antal dagar, inte år. Dessutom har jag hundratals lösenord att komma ihåg. Till och med xkcd-stil blir det svårt efter några.

Det är här lösenordshanterare kommer in, jag gillar KeePass men det finns många andra som i princip är desamma. Sedan kan du bara skapa en längre xkcd-lösenfras som du kan memorera (säg 10 ord). Sedan skapar du ett unikt 128-bitars riktigt slumpmässigt lösenord för varje konto (hex eller bas 64 är bra). 128-bitar kommer att vara tillräckligt starka för lång tid. Om du vill bli paranoid gå större är det inget extra arbete att generera 256-bitars hex-lösenord.

[1] Det är här minnet din sak kommer in, om du är på en komprometterad värd som du har tappat bort. Det spelar ingen roll om du skriver det eller använder ett program som KeePass för att kopiera och klistra in det om en angripare kan tangentlogga / läsa minne.

[2] Snarare än det svagare (men mer troligt) antagande att angriparen just har torrent en ordbok som heter ” Top Passw0rdz 4realz 111! ”.

[3] Visst att vi alla borde använda PBKDF2 osv … men många webbplatser finns fortfarande på SHA1. (Och de är bra)

Kommentarer

• @ Dick99999 moderna grafikprocessorer kan ha 6 GB minne på ett enda kort (även om det skulle ta två platser) och kan enkelt lagra en ordbok med några tusen ord.
• @NateKerkhofs Detta är läskigt och fantastiskt på samma gång. Min första (programmerbara) maskin hade 1mHz och 64kb ram och du pratar om 6GB videominne …
• ” 128-bitars riktigt slumpmässigt lösenord … ” Verkligen slumpmässigt? Är det inte ’ är det fortfarande pseudorandom?
• Detta borde vara accepterat svar om det inte finns någon annan anledning än det heliga krigets del.
• @Doorknob När du väl har valt meningsfulla kombinationer försvinner det mesta av entropin. Jag vann ’ t försöker uppskatta hur många meningar du kan välja, men det här är förmodligen närmare en av en miljard än en av 2 ^ 44.

Schneier skriver detta:

Det är därför det ofta citerade XKCD-schemat för att generera lösenord – strama ihop enskilda ord som ”correcthorsebatterystaple” – är inte längre bra råd. Lösenordsmakarna är på det här tricket.

men nyckeln till att förstå vad han egentligen är ute efter ligger lite längre i sin uppsats:

Det finns fortfarande ett schema som fungerar. Tillbaka 2008 beskrev jag ”Schneier-schemat ”

så att det är det. Ole ”Bruce vill hävda att hans -schema är det enda, det bästa, vinnaren, det ultimata schemat. Därför måste han säga nedsättande saker om” konkurrenterna ”, oavsett om sådana påståenden är vetenskapligt sunda eller inte.

I det här fallet har det alltid antagits att lösenordsgenereringsmetoden är känd för angriparen. Det är hela poängen med entropiberäkningar ; se analysen . Att angripare är ”på det här tricket” ändrar ingenting alls (när en angripare känner till lösenordsgenereringsmetoden, beskriver entropi-beräkningen exakt lösenordsstyrkan; när angriparen är inkompetent och känner inte till lösenordsgenereringsmetoden, är lösenordsstyrkan bara högre, med en mängd som är nästan omöjlig att kvantifiera).

Frågan om ”lösenord i minnet” är bara mer osammanhängande rörelser. Lösenord går nödvändigtvis till RAM någon gång, oavsett om du skriver dem eller kopierar och klistrar in dem från ett lösenordsskydd eller något liknande.

Min gissning är att Bruce var full.

Uppdatering : Schneier ombads specifikt att kommentera sin fördömande av lösenfrasen i en Reddit AMA som ägde rum den 2 augusti 2016. Han fortsatte att förespråka sitt lösenordsskapande system som överlägset alternativ till slumpmässiga ordlösenfraser. Schneier sa att hans schema ”ger dig mer entropi per minnesvärd karaktär än andra metoder” vilket är sant jämfört med karaktärer som utgör ord. Men detta är också irrelevant när ett system förlitar sig på att memorera ord snarare än tecken och du får kombinera tillräckligt många ord för att generera adekvat ”entropi” för din lösenfras som helhet.

Kommentarer

• Ja, jag tyckte att hans kommentarer var en udda avvikelse från hans typiska goda råd.Hans rekommenderade schema är förmodligen inte ’ t dåligt, men har inte ’ t utsatts för mycket faktiska tester. Lösenordsfrasen är ganska lätt att testa i jämförelse, och du ’ tror att det skulle tilltala kryptografen i honom. Kanske skumrade han bara över nyheterna om att knäcka lösenfraser för naturligt språk och såg ’ inte en skillnad mellan dessa och slumpmässiga ordlösenfraser.
• Ditt argument om att han behöver nedvärdera tävlingen misslyckas, eftersom han omedelbart efter att ha beskrivit sitt schema säger ” Ännu bättre är att använda slumpmässiga, omedelbara alfanumeriska lösenord (med symboler om webbplatsen tillåter dem) och en lösenordshanterare som Password Safe för att skapa och lagra dem ”.
• @wfaulk Password Safe är Bruce Schneier ’ skapande, så hans argument om tävlingen kvarstår. Ditt felmeddelande misslyckas 😉
• @AviD: Jag visste inte det helt. 😳
• Vad du ’ saknas, och tydligen också Schneier, är att det inte finns något ” trick ” till ” fånga upp till ”. Säkerheten i Diceware förutsätter redan att angriparen känner till schemat , i själva verket förutsätter att ordlistan i sig är känd. Det ’ spelar ingen roll om angriparen har din exakta ordlista och antalet ord: det finns helt enkelt för många kombinationer att gå igenom för att göra någon form av framgångsrik attack innan solen exploderar.

[Upplysning: Jag arbetar för AgileBits, tillverkarna av 1Password]

En av anledningarna till att jag förespråkade ett XKCD-liknande system (innan det kallades det) i Mot bättre huvudlösenord redan 2011 är just för att dess styrka lita inte på att angriparen vet vilket schema du använde. Om jag får citera mig själv

Det fantastiska med Diceware är att vi vet exakt hur säkert det till och med förutsätter att angriparen känner till det använda systemet. Säkerheten kommer från den äkta slumpmässigheten att tärna. Att använda fyra eller fem ord borde vara tillräckligt mot de troliga attackerna under de närmaste åren med tanke på den observerade hastigheten för lösenordshackare [mot 1Password Master Password]

Det XKCD-serietecknet inte kommunicerar effektivt är att valet av ord måste vara (enhetligt) slumpmässigt . Om du ber människor att välja ord slumpmässigt får du en kraftig fördom för konkreta substantiv. Sådana fördomar kan och kommer att utnyttjas.

Hur mycket styrka du vill ha

I en perfekt värld vill vi stärka vårt lösenord för att vara lika starka som de nycklar vi skyddar med den. Säg 128 bitar. Men trots dessa tekniker kommer människor inte att uppnå det. Så låt oss titta realistiskt på attacker och vad vi kan få våra små skamiga hjärnor att göra.

Med den ursprungliga Diceware-ordlistan med 7776 poster, du får cirka 12,9 bitar per ord som du använder. Så om du vill ha minst 64 bitar för ditt lösenord kommer fem ord att göra det.

Gissa lösenord är långsammare än att gissa tangenter

I det här avsnittet kommer jag fram till en mycket grov rygg i kuvertet uppskattar att det för en konstant summa dollar är 2 ^ 13 gånger långsammare att testa ett lösenord än att testa en AES-tangent.

Observera att testning av ett lösenord är mycket långsammare än att testa ett nyckel. Om rätt slags lösenords hashingscheman används är det möjligt att hålla de flesta angripare nere på under 100000 gissningar per sekund. Så även om vi kanske aldrig vill använda 50-bitars nycklar, kan det fortfarande vara vettigt att använda 50-bitars lösenord.

Om vi inte tänker begränsa oss till att kasta tärningar som i Arnold Reinhold s original Diceware schema från 1995, då kan vi använda en längre lista med ord. The Strong Password Generator i 1Password för Windows använder en lista med 17679 engelska ord mellan 4 och 8 bokstäver inklusive (borttagna från tabuord och ord som involverar en apostrof eller bindestreck). Detta ger cirka 14 bitar per ord. Så fyra av dessa ger dig 56 bitar, fem ger dig 70.

Återigen måste du vara uppmärksam på sprickhastigheter. Deep Crack kunde 1997 köra 92 miljarder DES-tester per sekund. Om vi antar att en avancerad specialdator kan utföra en miljon gissningar per sekund mot ett ganska väl hashat lösenord kan göra 1 miljon gissningar per sekund, så är lösenord idag cirka 16 bitar svårare att knäcka än DES-tangenterna var 1997.

Så låt oss titta på denna Stack Exchange-uppskattning för en 3,8 GHz-processor med dubbla kärnor: 670 miljoner nycklar per sekund.Om vi skulle anta $ 5000 i hårdvara kan vi lätt överstiga 10 miljarder nycklar per sekund. Så till en liknande hårdvarukostnad är nyckelknackning fortfarande mer än 2 ^ 13 gånger snabbare än lösenordssprickning.

Omarbetade mål för lösenordsstyrka

Arbetar med min uppskattning att det är 2 ^ 13 gånger dyrare att testa ett väl hashat lösenord än att testa en AES-nyckel, bör vi betrakta ett rimligt väl hashat lösenord som 13 bitar starkare än dess faktiska entropi med avseende på sprickbildning. Om vi vill uppnå 90 bitar av ”effektiv styrka” bör 77 bitar lösenordsstyrka göra det. Det uppnås med ett sex ord Diceware-lösenord (77,5-bitar) från den ursprungliga listan och 84,6 bitar med sex ord från en lista med 17679 ord.

Jag förväntar mig inte att de flesta använder lösenord som lång. Jag förväntar mig att folk kommer att använda saker som är 4 eller 5 ord långa. men om du verkligen är orolig för att NSA ska följa dina lösenord bör sex ord vara tillräckliga förutsatt att du använder ett ordentligt system för lösenordshashing.

Endast mycket grova uppskattningar

Jag spenderade inte mycket tid på att undersöka kostnader och riktmärken. Det finns många saker i mina uppskattningar att gräla med. Jag försökte vara konservativ (pessimistisk om det system som jag förespråkar). Jag har också varit vag om ”väl hashade lösenord” också. Återigen är jag mycket konservativ med avseende på lösenordshashing i 1Password. (För vårt nya dataformat har angriparna hållits under 20 000 gissningar per sekund och för vårt äldre dataformat har de nått 300 000 gissningar per sekund för multi -GPU-maskiner. Enligt mina uppskattningar här har jag ”plockat 1 miljon gissningar per sekund för ett” rimligt väl hashat lösenord ”.)

Några fler historiska anteckningar

Det totala idé för ”XKCD-liknande” lösenord går åtminstone så långt tillbaka som S / Key engångslösenord från början av 1980-talet. Dessa använde en lista över 2048 en genom fyra bokstäver. Ett sex ord S / Key-lösenord fick dig 66 bitar. Jag vet inte om denna idé att använda slumpmässigt valda ord från en lista för en lösenfras föregår S / Key.

1995 , Arnold Reinhold föreslog Diceware . Jag vet inte om han kände till S / Key vid den tiden. Diceware föreslogs i samband med att utveckla lösenfraser för PGP. Det var också innan de flesta datorer hade kryptografiskt lämpliga slumptalsgeneratorer. Så det handlar faktiskt om att kasta tärningar. (Även om jag litar på CSPRNG: erna på de maskiner jag använder, tycker jag fortfarande om att ”rulla upp ett nytt lösenord”).

I juni 2011 återupplivade jag intresset för Diceware i Mot bättre masterlösenord med lite ytterligare modifiering. Detta resulterade i min 15 minuters berömmelse. Efter att XKCD-serietidningen kom ut producerade jag en geek edition som gick igenom en del av matematiken.

I juli 2011 hade Randall Monroe plockat upp Diceware-liknande system och publicerat sina nu komisk . Eftersom jag inte är uppfinnaren av idén, tänker jag inte alls att bli uppförd av serietidningen. Som jag sa i min uppföljningsartikel

Vad tog mig nästan 2000 ord att säga i icke-tekniska termer kunde Randall Monroe sammanfatta i en serie. Detta visar bara kraften i matematik …

Men det finns en sak om hur serietidningen har tolkats som oroar mig. Det är tydligt för mig och människor som redan har förstått schemat att orden måste väljas genom en tillförlitligt enhetlig slumpmässig process. Att välja ord ”slumpmässigt” ur ditt huvud är inte en tillförlitligt enhetlig process .

Kommentarer

• Bra att du nämner Diceware i ett historiskt perspektiv och samtidigt erkänner det stora marknadsföringsjobb som XKCD gjorde för lösenfraser. Om ditt modifierade schema, förklaras någonstans varför 3 eller 2 bokstäver inte ingår i dessa ordlistor? se blog.agilebits.com/2013/04/16/… . Är det för att orden som ’ av ’ och ’ rad ’ kan också attackeras av ett ord offline? Se mina kommentarer om inlägget från Raestloz. Den ursprungliga Diceware-listan innehåller många ord på 1, 2 och 3 bokstäver.
• Utmärkt fråga! Mitt (möjligen felaktiga) tänkande vid den tiden var att jag också ville att lösenfraser skulle vara minimala. Jag ville se till att om någon använde en treords lösenfras, skulle den överstiga minst 12 tecken. Jag noterar att S / Key också tillåter ord på 1, 2 och 3 bokstäver.
• Jag kollade snabbt ordlistorna som min SimThrow-lösenfrasgenerator och testare använder.Den ursprungliga Diceware-listan har minst 1400 av dessa kollisioner som ’ alla ’ ’ hur ’ och ’ hur som helst ’. Det kan försämra en mening på fyra ord till tre ord om ingen avgränsare används. Det ’ är ett högt kollisionsnummer eftersom listan innehåller alla bokstäver och två bokstavskombinationer. Så det verkar som om du gjorde rätt val att inte inkludera två bokstäver. Diceware rekommenderar en minsta meningslängd på 17. Min generator uppskattar både ord- och teckenbaserade återställningstider för att klara webbplatser som endast tillåter korta lösenord (20).
• Jag kollade också följande ordlistor. S / Key : > 93 kollisioner, utvidgade listor USA : > 190 och min nederländska lista: > 750. Ett sätt att hantera detta är att rekommendera att du tar med ett avskiljartecken mellan orden i en fras.
• Var uppmärksam på att rulla tärningar är inte helt slumpmässigt. forbes.com/sites/davidewalt/2012/09/06/… Och insidescience.org/blog/2012/09/12/…

XKCD-lösenordsschemat är lika bra som det någonsin var. Säkerheten härrör inte från att det är okänt, men från att det är ett bra sätt att generera minnesvärda lösenord från ett stort sökutrymme. Om du väljer de ord som ska användas snarare än att generera dem slumpmässigt går den fördelen dock bort – människor är inte bra på att vara slumpmässig.

Lite om minnet är dåligt angivet, men det är ett problem: om lösenordsstöld skadlig programvara någonsin kommer på din dator, kommer det ”ll svep upp allt textliknande från RAM och hårddisken för att använda i en riktad attack mot dina konton.

Kommentarer

• +1 Jag don ’ tänker inte att XKCD-tekniken är död – det ’ är inte ’ ett trick ’ att kex ’ är på ’. Du kan känna tekniken inifrån och ut men det gör det inte ’ t gör det mer knäckbart om det ’ är tillräckligt slumpmässigt.
• @PiTheNumber om du ’ använder inte tillräckligt många ord eller en liten ordlista, då

Som andra har sagt, den attack som Bruce Schneier beskriver är effektiv när användaren väljer flera ord själv, utan att använda ett verktyg. Schneier skriver vanligtvis till en allmän publik, vilket sannolikt inte kommer att förstå skillnaden mellan självvalda ”slumpmässiga” ord och programvalda slumpmässiga ord. annat verktyg för att slumpmässigt välja ord från en ordlista, du måste använda den första sekvensen som det ger dig . Om du bestämmer dig, ” Jag gillar inte den där och kör den igen tills du gillar den, den är inte längre en slumpmässig lösenfras den är mänsklig vald.

Även om du använder ett skript, och även om du inte skadar slumpmässigheten genom att välja din favorit av flera sekvenser, finns det fortfarande möjligheten att en angripare kan utnyttja din PRNG (pseudo-slumpmässig om angriparen kan lära sig när du skapade lösenordet och vilken PRNG du använde, och kanske annan information om din PRNG, såsom nätverkstrafik som producerades med din PRNG ungefär samma tid, kan detta minska den effektiva entropin av din slumpmässiga lösenfras.

Kanske lite esoterisk, men om din PRNG är exploaterbar kommer inte 2 ^ 44-siffran att förverkligas helt. (Och om du antar att ”ingen kommer att försöka utnyttja min PRNG”, varför bryr du dig om att använda en riktigt säker lösenfras?)

Kommentarer

• +1 Intressant vinkel. Att utnyttja PRNG är uppenbart i samband med kryptering nycklar – det ’ är intressant att det verkar vara praktiskt taget en eftertanke här. Jag antar att typiska lösenord är så dåliga att PRNG: er känner sig säkra i jämförelse. Antagligen, om en angripare kan stjäla en lista med hashade lösenord, skulle det vara trivialt att hitta pwdChangedTime eller motsvarande? En annan anledning att avsluta praxis med lösenordsåldring?
• Snabbt bak på kuvertet. Om du uppdaterar lösenordet inom en minut efter att det genererats och den enda entropikällan i din PRNG är systemtiden, kanske du tittar på att skära ner saker så långt som 2 ^ 35 för nanosekundupplösning. Låter det rimligt?
• Antag att jag avvisar en fras eftersom jag inte ’ gillar ett ord och gör det 1000 gånger. Sedan har jag minskat ordlistan med 1000 ord. Är valet från den reducerade ordlistan fortfarande slumpmässigt? Om det fortfarande är så ger en 4-ords mening från en så reducerad 7776-ord Diceware-ordbok fortfarande (7776-1000) ^ 4 = 2.1E15 / 50.9 möjligheter / entropibitar, ner från 3.7E15 / 51,7 möjligheter / entropibitar för hela ordbok. Jag kan inte bedöma påverkan från slumpgeneratorn. Jag använder den från www.random.org
• @ Dick99999 Jag tror inte ’ att den ’ verkligen om antalet erbjudna val du utesluter när du väljer ett lösenord. Det ’ handlar om mönstret av vilka fraser du skulle utesluta om de presenteras för dig. En angripare kanske gissar att användaren föredrar kortare ord, ord som är lättare att skriva på ett QWERTY-tangentbord och ord utan versaler eller skiljetecken. denna strategi kan kraftigt krympa utrymmet för lösenfraser att utforska. I grund och botten är det ’ samma fråga som att bara gissa favoritsportlag, födelsedagar och barn ’ namn.
• @wberry Jag tror inte ’ att matematiken fungerar på det. Antag att du avvisar 1000 lösenfraser innan du hittar en du gillar. Då är det ’ en rimlig uppskattning att du bara gillar 1/1000 av det möjliga lösenordsutrymmet. Antag nu att en angripare helt kan gissa vilken 1/1000 av utrymmet som är din favorit – vilket minskar antalet möjligheter från 2 ^ 44 till 2 ^ 34, vilket är viktigt men inte så mycket att ett extra ord kan ’ t blockera förlusten. Dessutom är det inte nödvändigt om du begränsar dina avvisningar.

Det beror på. En sak du behöver förstå är att detta inte är säkerhet-för-dunkel: entropivärdena som används i serietidningen antar att angriparen redan vet att du använder den här metoden . Om angriparen inte vet hur du genererar lösenfrasen, så är entropin går massivt upp.

Tricket med XKCD-metoden är att du faktiskt måste använda en slumptalsgenerator och en bra ordlista: välj aldrig orden själv, inte ens ”slumpmässigt” (i citat eftersom människor faktiskt är riktigt dåliga att välja saker slumpmässigt, varför du inte borde göra det). Diceware har verktyg som hjälper dig att göra detta och tar till och med det slumpmässiga elementet ur datorns räckvidd med vanliga tärningar.

Mot en bred basattack – den typen av saker där en angripare fick en lista med lösenord från en webbplats och inte vet något om vars lösenord finns i listan – den är lika stark som den någonsin var. Precis som du säger kommer dess styrka från exponenternas kraft (och en bra ordlista).

Schneiers attack kan fungera, men bara i ett helt annat sammanhang. Hans attack förutsätter att du specifikt riktas mot en angripare som redan vet mycket om dig .Det här kanske inte verkar särskilt oroande till en början, för den stereotypa beslutsamma angriparen är en intelligensagent bakom en skärm, och de flesta av oss behöver inte oroa sig så mycket för dem: det finns bara så många av dem, och var och en kan bara har råd att bry sig om så många människor. Men det är faktiskt mer av ett problem än vad det först kan tyckas tack vare tillkomsten av sofistikerad skadlig kod. En malwareinstallation har råd att bry sig om dig även om angriparen inte gör det, och så hamnar du fortfarande inför en extremt beslutsam angripare. Ännu mer bestämd än en människa kan faktiskt vara mycket mindre kreativ.

Skadlig programvara som sammanställer information om dig ger ord som verkar viktiga för dig mycket hög prioritet i ordlistan. Det gör det för att de flesta väljer de ”slumpmässiga” orden själva, men därmed förvränger de faktiskt ganska starkt mot de ord som är viktigast för dem: det kan fortfarande ”kännas” slumpmässigt, men vissa ord är mycket mer benägna att komma upp än andra. Av den anledningen leder det ofta till relativt snabba träffar att ge dessa ord hög prioritet, och detta är ”tricket” som Schneier pratar om.

Men du kan fortfarande hindra Schneiers attack genom att använda verklig slumpmässighet . Fångsten är att detta kräver disciplin: alla beslut om vilka ord som ska användas i din lösenfras (förutom att välja ett bra ord måste tas helt ur dina händer. Det här är saker som Diceware kan hjälpa dig.

Kommentarer

• @Gilles: Anledningen till att entropin går ner om angriparen vet att metoden är att den ändrar lösenordets hela struktur. Om du inte ’ inte vet metoden, så ” rätt hästbatterihäftning ” ser ut som 216 symboler från ett tvåsymbolsalfabet: med andra ord 216 bitar. Om du vet att det ’ fyra engelska ord (och känner till XKCD

Styrkan matematik är ganska enkelt om ordval är slumpmässigt: (antal ord i ordlistan) ^ (antal ord i meningen), förutsatt att angriparen vet antalet i ordboken. Så en 5-ordsfras med en känd ( av angriparen !) 7776 ord Diceware-ordbok: har 7776 ^ 5 = 2.8E19 eller 64 bitar av entropi.

Det finns ett objekt som inte nämns i schemat: genom att bara lägga till 1 (slumpmässigt) tecken på en slumpmässig plats i hela frasen, är styrkan upp med cirka 10 bitar , se Diceware, valfria saker .

Ovanstående matematik tar inte heller hänsyn till avgränsningssymbolen mellan orden. Det kan lägga till ytterligare 5 bitar.

Kommentarer

• Poängen (eller åtminstone en av dem) i XKCD-serien är att lägga till ett slumpmässigt tecken på ett slumpmässigt ställe ökar svårigheten att memorera lösenordet mer än det ökar svårigheten att knäcka det.
• Sant för att memorera i allmänhet, inte sant för ett huvudlösenord för ett valv, tror jag. Jag ser ’ lätt att skriva ’ som den största fördelen. Jag stöter på fler och fler situationer där lösenordshanterare inte kan fylla i lösenordet (appar, WifI gästnätverk) och jag måste skriva dem.
• @Mark – de extra slumpmässiga (eller bara icke-ordboken) tecknen kan vara densamma över alla dina lösenord, vilket innebär att du inte kommer att glömma det ’. Du ’ Tjänar extra bitar av entropi åtminstone tills flera andra av dina lösenord äventyras då lösenordet fortfarande är xkcd-styrka …
• @imsotiredicantsleep – Det är ett mycket intressant förslag. Letade alltid efter en lösning för att göra denna förstärkningsteknik enklare att använda. Det kan kallas säkerhet genom dunkelhet eftersom angriparen kan dra nytta av kunskapen om den slumpmässiga karaktären och positionen. En liten avvägning tror jag mellan användarvänlighet och säker.
• @ Dick99999 absolut, det ’ är en avvägning. Men tills den konstanta komponenten äventyras kommer den att besegra en na ï en ordboksattack, och avsevärt sakta ner en mer sofistikerad. Jag är inte ’ instämmer inte i att det ’ är säkerhet genom dunkelhet, eftersom jag kan säga att jag använder -tekniken utan att förlora entropin som de möjliga värdena ger mig. Den största svagheten är att när den konstanta delen är känd har du offrat lösenordsfastigheter som kunde ha slumpmässigt.

Jag skulle också vilja lägga till ett ja svar också, men för av andra skäl. Det är inte ett bra råd [i allmänhet] på grund av längdbegränsningar:

• Webbplatser som Skype, ING, eBay och i mitt land begränsar Binckbank och KPN lösenord till 20 tecken. (Den bankgränsen är 15, men den använde tvåfaktorsbehörighet)
• Med en genomsnittlig längd på 4,5 tecken / ord för en kort ordbok på 3000-8000 ord kan du bara använda 3-4 ordfraser.
• Vid användning av stora ordböcker kan genomsnittet bara vara 6-7: 3 ord
• Om webbplatsen insisterar på att använda en symbol och ett nummer i lösenordet, finns endast 18 tecken tillgängliga för frasen.

Dessa längder skyddar bara mot online-attacker. För offlineattacker beror på nyckelavledning och hashfunktion, iteration räknas och sprickmaskinvara som används av appens webbplats, om en fras på 3-4 ord ger tillräckligt skydd.

Kommentarer

• Webbplatser som begränsar längden på lösenord är ofta en bra indikator på att deras lösenordsförvaringssystem är mycket osäkert. Spring iväg. Sammantaget tenderar kraven på lösenordsstyrka att vara mer skadliga än användbara, IMO (både för säkerhet och minnesvärdhet).
• Lägg till Suntrust i listan över lösenord som är begränsade till 15 tecken. Jag undrar vad som händer med den branschen ..
• På baksidan är det ’ betydligt lättare att skriva ’ correcthorsebatterystaple ’ på en smartphone än att fortsätta växla mellan gemener, versaler, siffror och skiljetecken.
• Låga lösenordsgränser ’ t betyder bara osäkra lösenordsförvaringsmetoder – de betyder att lösenord lagras i klartext eller är krypterade (inte hashade). @ Á ngel Mina lösenord för alla Microsoft-relaterade konton är längre än så, så jag ringer till BS. För åldrar sedan, före NTLM, begränsades Windows-lösenord till 16 tecken, iirc. Det föregår XP och är knappast relevant.
• @Zenexer När det gäller Microsoft-konton: Microsofts onlinekonton (live.com, Office 365, etc.) är begränsade till 16 tecken (bokstäver, siffror och vissa symboler är tillåtna ).

Det är viktigt att ha rätt sammanhang. xkcd comic jämför Tr0ub4dor&3 vid en antagen 28-bitars entropi (även om jag beräknar det som 34.6) till correcthorsebatterystaple och dess antagna 44 bitar entropi (en fyra ord diceware -kod är 51,7 bitar … men ett av dessa ord är inte diceware. Med en enkel ordbok på 100 000 ord beräknar jag att den är 66,4 bitar.

Låt oss först göra det lättare att förstå. Det finns 94 utskrivbara tecken. Ett lösenord med ett tecken har log₂(94) = 6.55 entropibitar. Två tecken har log₂(94²) = 13.10 entropibitar.Du kan dela den slutliga entropin av ett lösenordsschema med 6,55 för att bestämma ekvivalent komplexiteten för ett rent slumpmässigt lösenord, mätt i tecken.

Därför:

• 28 bitar entropi ≈ 4,3 tecken lösenord (mycket dåligt!)
• 44 bitar entropi ≈ 6,7 tecken lösenord (även dåligt)
• 66,4 bitar entropi ≈ 10,1 tecken lösenord (okej för 2016)

För att lita på xkcds nummer kan du se varför Schneier var orolig. Detta verkar lite överdrivet, eftersom de flesta angripare fortfarande kommer att ge upp efter tio eller så tecken ^{[citat behövs]} – det borde ta några år för ett stort kluster att bryta ett 10-char MD5-hashlösenord – men uppenbarligen om en bra angripare känner till ditt schema är absolut teckenlängd inte ett problem.

Systemets totala komplexitet är viktigast. Du måste anta det värsta fallet (att angriparen känner till ditt exakta schema) . Det är en bra idé att dessutom se till att ditt lösenord är 11+ tecken ( när det är tillåtet ), men att det är en sekundär prioritet (och det kommer gratis med lösenfraser ).

Skapa lösenfraser med fyra ord plus ett lösenord

Här är mitt råd om skapande av lösenord (med uppskattningar av entropi):

• Gör en meningslös ”mening” med 4+ ord om 4+ tecken vardera (100.000⁴)
• Ingen av dessa ord kan kopplas till ni –eller varandra– på något sätt
• Använd versaler, blanksteg och minst två symboler eller skiljetecken (32²)
• Minst ett ord ska misslyckas med stavningskontroll (t.ex. leetspeak, främmande ord, vardera 64)
• Inkludera minst ett annat ”fel” (stavning / grammatik / syntax, entropi okänd)
• Mellan två ord, lägg till ett traditionellt ”slumpmässigt” lösenord för 7+ tecken (92⁷)

Detta bör vara minst log₂(100000⁴ × 32 × 3 × 64 × 92⁵) = 112 bitar av entropi (som är mycket stark, ≈17 tecken). Jag hoppade över stora bokstäver (jag antar att bara den första tecknet är versal) och en symbol (jag antar att den slutar med ., ! eller ?, så den andra symbolen har en komplexitet på 3) och jag antog också att ”slumpmässig” inte är ganska slumpmässig och beräknade koden som en ekvivalent med fem tecken (strikt efterlevnad av ovanstående formel ger dig 128+ bitar av entropi vid ≈20 tecken).

Den sista punkten är värt att upprepa:

Människor är väldigt dåliga att generera slumpmässighet

Mycket väldigt få mänskliga genererade ”slumpmässiga” karaktärskoder även närmar sig sann slumpmässighet. Det kommer att finnas mönster i kodrelaterade till personens tangentbord, favoritnummer och / eller ett antagande om att ett visst dunkelt ord är otänkbart.

Jag utformade detta schema för att vara robust mot människors inneboende brist på slumpmässighet, antar en begränsad vokabulär (säg de 2600 orden i Basi c engelska ), användning av relaterade ord (bestraffas genom att bara räkna tre ord) och ett lösenord begränsat till bara entropin av sex alfanumeriker, log₂(2600³ × 62⁶) är fortfarande 70 bitar (≈10,6 tecken).

Låt inte detta vattna ner din lösenfras! Detta avsnitt är närvarande för att visa att detta schema har viss motståndskraft mot mänsklig entropi val, inte för att uppmuntra dåliga val.

Det enda verkliga problemet kommer från människor som tar citat eller texter som sina fyra ord. Dessa lösenfraser besegras trivialt om citatet eller texten kan gissas (säg genom att titta på dina Facebook-gillanden) eller annars skulle ha en entropi på cirka 6 slumpmässiga tecken vid en spricktid på 30 sekunder (MD5) till 17 dagar (PBKDF2) .

Du kan använda min entropitabell för att beräkna entropin för ditt lösenfrasschema.

_{(Var inte orolig för att lösenord kort lever i minnet såvida inte du är en utvecklare}

Kommentarer

• Det bör också noteras att icke- ASCII karaktärer är som silverkulor och besegrar de flesta attacker automatiskt. Ett lösenord för ••••••••• (nio punkttecken) är pinsamt säkert (och ser samma maskerade ut som ommaskerat!) På grund av längd och dunkelhet, även om det ’ skulle vara en hemsk idé att faktiskt bero på just detta faktum. Sätt ett icke-ASCII-tecken i ditt lösenord + 4word och din komplexitet skyrockets (för att beräkna, använd dess unicode-värde), men kanske på bekostnad av bärbarhet (vad händer om du ’ använder en vän ’ s smartphone?)