System som använder lösenord för autentisering måste ha något sätt att kontrollera lösenordet för att få åtkomst. Om de giltiga lösenorden helt enkelt lagras i en systemfil eller databas, kommer en angripare som får tillräcklig tillgång till systemet att få alla användarlösenord, vilket ger angriparen tillgång till alla konton i det attackerade systemet och eventuellt andra system där användare använder samma eller liknande lösenord. Ett sätt att minska denna risk är att bara lagra en kryptografisk hash av varje lösenord istället för själva lösenordet. Standard kryptografiska haschar, till exempel Secure Hash Algorithm (SHA) -serien, är mycket svåra att vända, så en angripare som får tag i hashvärdet kan inte återställa lösenordet direkt. Men kunskapen om hashvärdet låter angriparen snabbt testa gissningar offline. Lösenordssprickningsprogram finns allmänt tillgängliga som kommer att testa ett stort antal provlösenord mot en krypterad kryptografisk hash.
Förbättringar i datorteknik ökar kontinuerligt den takt som gissade lösenord kan testas. Till exempel utvecklade Georgia Tech Research Institute 2010 en metod för att använda GPGPU för att knäcka lösenord mycket snabbare. Elcomsoft uppfann användningen av vanliga grafikkort för snabbare lösenordsåterställning i augusti 2007 och lämnade snart in ett motsvarande patent i USA. År 2011 fanns kommersiella produkter tillgängliga som hävdade möjligheten att testa upp till 112 000 lösenord per sekund på en vanlig stationär dator med en avancerad grafikprocessor för den tiden. En sådan enhet kommer att knäcka ett lösenord på 6 bokstäver på en dag. Observera att arbetet kan distribueras över många datorer för en ytterligare hastighet som är proportionell mot antalet tillgängliga datorer med jämförbara GPU: er. Det finns speciella nyckelsträckningshashar som tar relativt lång tid att beräkna, vilket minskar den takt som gissning kan ske. Även om det anses vara bästa praxis att använda nyckelsträckning gör många vanliga system det inte.
En annan situation där snabb gissning är möjlig är när lösenordet används för att bilda en kryptografisk nyckel. I sådana fall kan en angripare snabbt kontrollera om ett gissat lösenord avkodar krypterad data. Till exempel hävdar en kommersiell produkt att testa 103 000 WPA PSK-lösenord per sekund.
Om ett lösenordssystem bara lagrar hash för lösenordet kan en angripare beräkna hash-värden för vanliga lösenordsvarianter och för alla lösenord kortare än en viss längd, vilket möjliggör mycket snabb återställning av lösenordet när dess hash erhållits. Mycket långa listor med förberäknade lösenordshashar kan lagras effektivt med regnbågsbord. Denna attackmetod kan tas bort genom att lagra ett slumpmässigt värde, kallat kryptografiskt salt, tillsammans med hashen. Saltet kombineras med lösenordet vid beräkning av haschen, så en angripare som förberäknar ett regnbågstabell måste lagra sin hash för varje lösenord med alla möjliga saltvärden. Detta blir omöjligt om saltet har ett tillräckligt stort intervall, säg ett 32-bitarsnummer. Tyvärr använder många autentiseringssystem i vanlig användning inte salter och regnbågsbord finns tillgängliga på Internet för flera sådana system.
Entropi som ett mått på lösenordsstyrka Redigera
Det är vanligt i datorindustrin för att specificera lösenordsstyrka i termer av informationsentropi som mäts i bitar och är ett begrepp från informationsteori. I stället för antalet gissningar som behövs för att hitta lösenordet med säkerhet, ges bas-2-logaritmen för det numret, vilket vanligtvis kallas antalet ”entropibitar” i ett lösenord, även om detta inte är exakt samma kvantitet som informationsentropi. Ett lösenord med en entropi på 42 bitar beräknat på detta sätt skulle vara lika starkt som en sträng på 42 bitar som valts slumpmässigt, till exempel genom ett rättvist myntkast. Sagt på ett annat sätt, ett lösenord med en entropi på 42 bitar skulle kräva 242 (4,398,046,511,104) försök att uttömma alla möjligheter under en brute force-sökning. Genom att öka lösenordets entropi med en bit fördubblas antalet gissningar som krävs, vilket gör en angripares uppgift dubbelt så svår. I genomsnitt måste en angripare prova hälften av det möjliga antalet lösenord innan den hittar rätt.
Slumpmässiga lösenordRedigera
Slumpmässiga lösenord består av en rad symboler med specificerad längd som tagits från en uppsättning symboler med ett slumpmässigt val process där varje symbol lika sannolikt kommer att väljas. Symbolerna kan vara enskilda tecken från en teckenuppsättning (t.ex. ASCII-teckenuppsättningen), stavelser som är utformade för att bilda uttalbara lösenord eller till och med ord från en ordlista (vilket bildar en lösenfras ).
Styrkan hos slumpmässiga lösenord beror på den faktiska entropin för den underliggande talgeneratorn, men dessa är ofta inte riktigt slumpmässiga utan pseudorandom.Många allmänt tillgängliga lösenordsgeneratorer använder slumptalsgeneratorer som finns i programmeringsbibliotek som erbjuder begränsad entropi. De flesta moderna operativsystem erbjuder dock kryptografiskt starka slumptalsgeneratorer som är lämpliga för generering av lösenord. Det är också möjligt att använda vanliga tärningar för att generera slumpmässiga lösenord. Se starkare metoder. Slumpmässiga lösenordsprogram har ofta möjlighet att säkerställa att lösenordet som följer följer en lokal lösenordspolicy. till exempel genom att alltid producera en blandning av bokstäver, siffror och specialtecken.
För lösenord som genereras av en process som slumpmässigt väljer en sträng av symboler med längden, L, från en uppsättning N möjliga symboler antal möjliga lösenord kan hittas genom att höja antalet symboler till kraften L, dvs. NL. Öka antingen L eller N kommer att stärka det genererade lösenordet. Styrkan för ett slumpmässigt lösenord mätt med informationsentropin är bara bas-2-logaritmen eller log2 för antalet möjliga lösenord, förutsatt att varje symbol i lösenordet produceras oberoende. Således ges ett slumpmässigt lösenordsinformationsentropi, H, med formeln:
H = log 2 NL = L log 2 N = L logg N logg 2 {\ displaystyle H = \ log _ {2} N ^ {L} = L \ log _ {2} N = L {\ log N \ över \ log 2}}
där N är antalet möjliga symboler och L är antalet symboler i lösenordet. H mäts i bitar. I det sista uttrycket kan logg vara till vilken bas som helst.
Symboluppsättning | Symbol räkna N | Entropi per symbol H |
---|---|---|
Arabiska siffror (0–9) (t.ex. PIN) | 10 | 3.322 bitar |
hexadecimala siffror (0–9, A – F) (t.ex. WEP-nycklar) | 16 | 4.000 bitar |
Skiftlägeskänsliga latinska alfabetet (a – z eller A – Z) | 26 | 4.700 bitar |
Skiftlägeskänsliga alfanumeriska (a – z eller A – Z, 0–9) | 36 | 5.170 bitar |
Skiftlägeskänsligt latinskt alfabet (a – z, A – Z) | 52 | 5.700 bitar |
Skal känsliga alfanumeriska (a – z, A – Z, 0–9) | 62 | 5.954 bitar |
Alla ASCII-utskrivbara tecken utom utrymme | 94 | 6.555 bitar |
Alla Latin-1 tilläggstecken | 94 | 6.555 bitar |
Alla ASCII-utskrivbara tecken | 95 | 6,570 bitar |
Alla utökade ASCII-utskrivbara tecken | 218 | 7.768 bitar |
Binära (0–255 eller 8 bitar eller 1 byte) | 256 | 8.000 bitar |
Ordlista för diceware | 7776 | 12.925 bitar per ord |
En binär byte uttrycks vanligtvis med två hexadecimala tecken.
För att hitta längden behövs L för att uppnå önskad styrka H, med ett lösenord som slumpmässigt dras från en uppsättning N-symboler, beräknar man:
L = H log 2 N {\ displaystyle L = {H \ over \ log _ {2} N}}
rundad upp till nästa största heltal.
Följande tabell använder denna formel för att visa de nödvändiga längderna på riktigt slumpmässigt genererade lösenord för att uppnå önskade lösenordsentropier för vanliga symboluppsättningar:
Arabiska och siffror | Hexadecimal | Fall okänslig | Skiftlägeskänslig | Alla ASCII | Alla utökade ASCII |
Diceware ordlista |
|||
---|---|---|---|---|---|---|---|---|---|
Latin och alfabet | alfa- numerisk |
Latin och alfabet | alfa- numeriska |
utskrivbara tecken | |||||
8 bitar (1 byte) | 3 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 1 ord |
32 bitar (4 byte) | 10 | 8 | 7 | 7 | 6 | 6 | 5 | 5 | 3 ord |
40 bitar (5 byte ) | 13 | 10 | 9 | 8 | 8 | 7 | 7 | 6 | 4 ord |
64 bitar (8 byte) | 20 | 16 | 14 | 13 | 12 | 11 | 10 | 9 | 5 ord |
80 bitar (10 byte) | 25 | 20 | 18 | 16 | 15 | 14 | 13 | 11 | 7 ord |
96 bitar (12 byte) | 29 | 24 | 21 | 19 | 17 | 17 | 15 | 13 | 8 ord |
128 bitar (16 byte) | 39 | 32 | 28 | 25 | 23 | 22 | 20 | 17 | 10 ord |
160 bitar (20 byte) | 49 | 40 | 35 | 31 | 29 | 27 | 25 | 21 | 13 ord |
192 bitar (24 byte) | 58 | 48 | 41 | 38 | 34 | 33 | 30 | 25 | 15 ord |
224 bitar (28 byte) | 68 | 56 | 48 | 44 | 40 | 38 | 35 | 29 | 18 ord |
256 bitar (32 byte) | 78 | 64 | 55 | 50 | 45 | 43 | 39 | 33 | 20 ord |
Mänskliga genererade lösenord Redigera
Människor är notoriskt dåliga för att uppnå tillräcklig entropi för att producera tillfredsställande lösenord. Enligt en studie som involverade en halv miljon användare uppskattades den genomsnittliga lösenordsentropin till 40,54 bitar. Några scenmagiker utnyttjar denna oförmåga att underhålla, på ett mindre sätt, genom att dividera förmodade slumpmässiga val (av siffror, säg) gjorda av publikmedlemmar.
Således, i en analys av över 3 miljoner lösenord med åtta tecken , bokstaven ”e” användes mer än 1,5 miljoner gånger, medan bokstaven ”f” användes endast 250 000 gånger. En enhetlig fördelning skulle ha haft att varje karaktär hade använts cirka 900 000 gånger. Det vanligaste numret som används är ”1”, medan de vanligaste bokstäverna är a, e, o och r.
Användare använder sällan större teckenuppsättningar för att skapa lösenord. Exempelvis avslöjade hackningsresultat från ett MySpace-nätfiske 2006 34 000 lösenord, varav endast 8,3% använde blandade bokstäver, siffror och symboler.
Full styrka förknippad med användning av hela ASCII-teckenuppsättningen ( siffror, stora bokstäver och specialtecken) uppnås endast om varje möjligt lösenord är lika troligt. Detta verkar tyda på att alla lösenord måste innehålla tecken från var och en av flera teckenklasser, kanske stora och små bokstäver, siffror och icke-alfanumeriska tecken. Faktum är att ett sådant krav är ett mönster i valet av lösenord och kan förväntas minska en angripares ”arbetsfaktor” (enligt Claude Shannons ord). Detta är en minskning av lösenordets ”styrka”. Ett bättre krav skulle vara att kräva ett lösenord som INTE innehåller något ord i en online-ordlista, eller namnlista eller något registreringsskyltmönster från någon stat (i USA) eller land (som i EU). Om mönstrade val krävs, kommer människor troligtvis att använda dem på förutsägbara sätt, som att skriva versaler, lägga till ett eller två siffror och ett specialtecken. Denna förutsägbarhet innebär att ökningen av lösenordsstyrkan är liten jämfört med slumpmässiga lösenord.
NIST Specialpublikation 800-63-2Edit
NIST Specialpublikation 800-63 från juni 2004 (revision 2) föreslog ett system för att approximera entropin för mänskliga genererade lösenord:
Med hjälp av detta schema uppskattas ett åtta tecken mänskligt valt lösenord utan versaler och icke-alfabetiska tecken ELLER med endera men av de två teckenuppsättningarna att ha 18 bitar entropi. NIST-publikationen medger att vid tidpunkten för utvecklingen fanns lite information tillgänglig om det verkliga valet av lösenord. Senare forskning om mänskligt valt lösenordsentropi med hjälp av nyligen tillgängliga verkliga data har visat att NIST-schemat inte ger ett giltigt mått för entropiuppskattning av mänskligt valda lösenord. Revisionen av SP 800-63 i juni 2017 (Revision 3) tappar detta tillvägagångssätt.
Överväganden om användbarhet och implementering Redigera
Eftersom de nationella tangentbordimplementeringarna varierar kan inte alla 94 ASCII-utskrivbara tecken användas överallt. Detta kan utgöra ett problem för en internationell resenär som ville logga in på fjärrsystem med ett tangentbord på en lokal dator. Se tangentbordslayout. Många handhållna enheter, som surfplattor och smarta telefoner, kräver komplexa skiftningssekvenser eller tangentbordsappbyte för att ange specialtecken.
Autentiseringsprogram varierar i vilka tecken de tillåter i lösenord. Vissa känner inte igenom skillnader i fall (t.ex. stora bokstäver ”E” anses motsvara små bokstäver ”e”), andra förbjuder några av de andra symbolerna. Under de senaste decennierna har system tillåtit fler tecken i lösenord, men begränsningar finns fortfarande. System varierar också i den maximala längden på tillåtna lösenord.
Som en praktisk fråga måste lösenord vara både rimliga och funktionella för slutanvändaren och vara tillräckligt starka för det avsedda syftet. Lösenord som är för svåra att komma ihåg kan glömmas bort och är därför mer benägna att skriva på papper, vilket vissa anser vara en säkerhetsrisk. Däremot hävdar andra att det att tvinga användare att komma ihåg lösenord utan hjälp bara kan rymma svaga lösenord och därmed utgör en större säkerhetsrisk. Enligt Bruce Schneier är de flesta bra på att säkra sina plånböcker eller plånböcker, vilket är ett ”bra ställe” att lagra ett skrivet lösenord.