Felet här är att tro att extra lösenordsregler ökar säkerheten. De gör inte. De ökar användarnas irritation; och de får användarna att välja lösenord som är svårare att memorera. Av någon konstig psykologisk anledning tror de flesta att ett lösenord med symboler som inte är bokstäver är "säkrare" på något ontologiskt sätt än ett lösenord med endast bokstäver. Detta är dock helt obefogat.

Det finns en "lösenordsregel" som inte är skadlig för säkerheten: en minsta lösenordslängd. Detta beror på kombinationen av två saker:

• De mest dumma brutala kraftattacken räknar upp alla symbolsekvenser, som börjar med sekvenser på 1, sedan 2 och så vidare. I den meningen kan ett lösenord som endast innehåller fyra symboler sägas vara omöjligt att försvaga.

• Användare förstår tanken att räkna upp alla små lösenord. De är redo att acceptera att de behöver skriva minst 6 eller 7 bokstäver.

Alla andra regler kommer i bästa fall vara neutrala, men de flesta kommer att faktiskt minskar säkerheten, eftersom de kommer att få användare att:

1. utforma och dela med varandra "metoder" för att generera lösenord som din server kommer att acceptera, metoder som vanligtvis har mycket skiljetecken tecken men väldigt lite entropi;

2. skriv ner sina lösenord som är svåra att komma ihåg;

3. återanvänd lösenord på andra system , av samma anledning till svår memorering.

"Lösenordsstyrkemätare" är också skadliga eftersom:

• De är inte och kan inte vara pålitlig. En mätare för lösenordsstyrka mäter bara hur länge ett givet lösenord skulle stå mot den exakta brute force-strategin som inkarneras av mätarkoden, men ingen angripare är begränsad att följa exakt samma strategi. > Lösenordsstyrkemätare kan inte mäta entropin som rådde i lösenordsvalet, eftersom de bara ser resultatet (lösenordet i sig).

• De förvandlar lösenordsval till ett spel som uppmuntrar kvicka strategier från användarens sida, och intelligens är precis vad vi inte vill ha för lösenord. Säkra lösenord strävar efter slumpmässighet.

Vad kan kan hjälpa mycket är att tillhandahålla ett lösenordsgenereringssystem. Var noga med att göra systemet frivilligt : du vill att användare villigt vill använda det, inte tvinga det på dem, för att de inte skulle göra uppror (och skriva ner lösenord, dela och återanvända).

Så min rekommendation skulle vara:

• Avvisa lösenord som är kortare än 7 tecken (eftersom du har ett lindringssystem mot online-attacker - nämligen autolås i 10 minuter efter 5 fel försök - du kan tolerera relativt korta lösenord). MEN INGEN ANNAN REGEL. Varje sekvens med 7 eller fler tecken är bra.
• Ange en eller, ännu bättre, flera valfria lösenordsgenereringsmekanismer, t.ex. diceware, "rätt häst", och så vidare.
• Uppmuntra användningen av lösenordshanterare.
• Om möjligt, försök hitta något annat än lösenord för autentisering av användare.

Mitt påstående är att du skjuter saker i en något sned riktning, inte precis rätt. I synnerhet är lösenordsregler som insisterar på vissa specifika tecken en dålig sak (en vanlig sak, men en dålig sak ändå).

Ett index över entropi -värden ( dela gånger med antalet noder —statliga aktörer har massor av noder):

 BIT ~ RAND CRACK CRACKDICTIONARY COUNT ENTROPY CHARS MD5 PBKDF2̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ph Alfabetiska siffror (bokstäver, siffror) 62 5,95 0,9 0s 0s Random printable char (any tangent på ett amerikanskt tangentbord) 94 6,55 1,0 0s 0sDiceware-ordboksord 7776 12,92 2,0 0s 0sStandard amerikansk engelska (en_US) diktord 100k 16,61 2,5 0s 0sStor amerikansk engelsk ordbok 650k 19,31 2,9 0s 1sEtt ord i valfri Wikipedia (vilket språk som helst) 58.4M 25.80 3.9 0s 58sStandard sv_US-ordbok med raNDomIZED CASE 6.3M 22.60 3.4 0s 6sStandard en_US-ordbok med l33t-variationer 6.3M 22.60 3.4 0s 6sStd en_US w / typos + (antingen randfodral eller leet) 38M 25.18 3.8 0s 38sStd en_US w / randfodral + stavfel + leet 2.4B 31.18 4.8 0s 41mWikipedia-ord med raNDomIZed cASE (eller l33t) 3.7B 31.80 4.9 0s 1hWikipedia word w / typos + (rand case xor leet) 22B 34.39 5.2 0s 6 orderordning: 5 nedre, 1 special, 1 nummer, 1 övre 1e11 36.52 5.6 2s 1drandordning: 6 lägre och två av övre / num / special 4e11 38,67 5,9 10s 5drand ordning: 6 nedre, 1 spec / övre, år 1900-2100 4e12 41,70 6,4 1m 49drand ordning: 7 nedre och två av övre / num / special 1e13 43,37 6,6 4m 131drand ordning: 8 nedre och två av övre / num / special 3e14 48,07 7,3 2h 4y * 4 ord diceware lösenfras 4e15 51,70 7,9 2d 8y * 8 char (slumpmässigt utskrivbar) lösenord 6e15 52.44 8.0 2d 9y *
5-ords lösenordsfras 3e19 64,62 9,9 6y * 27y * 10 tecken (slumpmässigt utskrivbar) lösenord 5e19 65.55 10.0 6y * 29y * 4 standard sv_US-ord 1e20 66.44 10.1 7y * 31y * 3 st en_US-ord och ett stort en_US-ord 6e20 69.10 10.5 11y * 35y * 3 st en_US ord och 3 slumpmässiga utskrivbara tecken 8e20 69.46 10.6 12y * 35y * 6 ord diceware lösenfras 2e23 77.55 11.8 26y * 47y * 

^{"Alla Wikipedia" inkluderar Wiktionary, Wikibooks, etc, på alla språk, med 58,4 miljoner unika ord 2009. Diceware var grunden för xkcd-serierna. Jag antar en ordstorlek på sex tecken för slumpmässigt blandat skiftläge (så det finns 2⁶ extra iterationer) och jag antar att leetvariationer är lika rikliga som blandade skiftlägen. Jag använder ett värde på sex för avsiktliga stavfel / felstavningar.}

^{Sprickor är uppskattningar för toppmoderna sprickningssystem med en nod, med uppgraderingar var 18: e månad för att ta hänsyn till Moores lag (när du ser en asterisk, * ). Ett utrymme anses vara knäckt när hälften av det har undersökts. GPU-baserad krackning kan testa MD5s vid 23B / s på en enskild datornod . PBKDF2 är mer robust, uppskattat till 300k / s på ett 4-GPU-system 2013 (för 27 månader sedan → 2 27/18 , så 300k × 2.828 = 849k / s → avrundat till 1M / s).}

^{(Anmärkning till mig själv: läs och införliva / motbevisa Jeffrey Goldbergs lösenordssprickande matematik i Quora)}

Frågan klargjordes i kommentarer till mitt andra svar (som jag lämnar eftersom det fortfarande kan vara hjälpsam). Det frågar egentligen bara om leetspeak ska tillåtas eller inte. Tvåfaktorautentisering används redan för områden med hög säkerhet.

Ordet "troubador" finns inte i min ordlista utan i min stora ordbok. Att använda den första bokstaven i ett ord är inte slumpmässigt blandat skiftläge (det är en vanlig lösenordstopologi), så det fördubblar bara antalet. Dess slumpmässiga utskrivbara teckenekvivalent är därför log₂ (650k × 2⁶ × 2) / 6.55 som bara är fyra tecken!

Därför Tr0ub4dor&3 motsvarar sex slumpmässiga utskrivbara tecken av komplexitet. Ett svagt lösenord, men ändå ungefär lika starkt som de flesta lösenord som människor skapar för att minimalt passa komplexitetskrav.

Om sex slumpmässiga tecken är för svaga bör du inte tillåta "leetspeak" ordbokslösenord.

För att vara helt grundlig kanske du också vill ha en stor ordlista så att du kan räkna ord som jag har, annars ett lösenord som presidentclinton (33,22 bitar, 5 tecken, lägre i verkligheten på grund av att de är relaterade) accepteras av ditt system.

Ytterligare lösenordsregler bör alltid tempereras med följande regel:

"Ju svårare det är att få ett giltigt lösenord och hålla det aktuellt, desto mer troligt kommer folk att skriva ner dem i deras dagplanerare. "

Följaktligen är din fråga social. Hur mycket utbildning om bra lösenordshantering kan du ge kontra hur mycket efterlevnad du kan ge. Du måste balansera detta för ditt eget företag. Det låter som om du har viktig information att skydda ... är det någon som utbildar operatörer hur man arbetar med sådan känslig information? Eller förlitar de sig blint på dig och en hashalgoritm för att göra det åt dem.

Bara för att det är annorlunda skulle jag överväga att föreslå en inlärningsupplevelse när ett dåligt lösenord ges. Jag tror att det kan vara en balans mellan tillvägagångssätten. Ännu viktigare, det kan inspirera dig att hitta en ännu bättre lösning:

• Ha en minsta lösenordslängd. Detta är kravet på bara ben, och du måste genomdriva det
• Om ett lösenord är svagt, låt dem veta att det är svagt och erbjuda att låta dem använda det ändå ( med lite text som indikerar att du litar på dem för att skydda sina egna referenser ordentligt)
• När du accepterar ett svagt lösenord, inkludera lite text som förklarar vad du anser vara svag vid det ("Det ser ut som att du använde l33t för att göra din lösenord ser säkrare ut. Gissa vad: det är det inte! Det här lösenordet är ungefär 45000 gånger svagare än du faktiskt tror att det är ")

Om du inte är rädd för att någon stjäl och råkar tvinga dina lösenord, är ditt mest troliga fall att ett lösenord upptäcks en phishing-attack. Krav på lösenordskomplexitet skyddar dig inte från nätfiskeattacker.

Om du använder mycket komplexa lösenord kommer användarna att hitta ett lösenord som fungerar och håller fast vid det, när det löper ut kommer de att göra den mest mindre ändringen och Fortsätt. Det betyder att en bestämd phisher kommer att kunna gissa det nya lösenordet ganska snabbt.

Överväg att använda tvåfaktorsautentisering eftersom inget lösenordskomplexitetsschema skyddar dig från användaråtgärder. (Kom ihåg att användare också är människor och vill få sina jobb klara utan att spendera hela dagen på ett lösenord)

BTW, här är några frågor relaterade:

Är regler för lösenordskomplexitet kontraproduktivt?

Rekommenderad policy för lösenordskomplexitet

Jag skulle säga att 8 är för låg, till och med 9 är en storleksordning säkrare (bokstavligen) för något liknande. Du vill verkligen överväga tvåfaktorautentisering med tanke på vad detta innehåll är.

Tänk också på hur människor närmar sig mandat som stora bokstäver (nästan alltid det första tecknet) och siffror (nästan alltid det sista tecknet). Dessa försvagar faktiskt din entropi. Jag skulle till och med föreslå att du använder ord, så länge du kan göra det klart att de inte ska vara relaterade och absolut inte ett citat av något slag.

Den säkraste men minnesvärda lösenfrasen du kan ha är en samling ord, varav en är lösenord. En angripare måste veta var man ska lägga den koden eller anta att det riktigt långa lösenordet kan ha koden var som helst.

Ett trick som banker använder för att undvika nyckelloggare är att ha bilder som du kan klicka på. Vissa, som ING Direct (innan CapitalOne köpte dem och ändrade metoden), använde ett stift-system; ditt lösenord var en fyrsiffrig stift som bara kunde matas in med en mus eller genom att trycka på slumpmässiga tangenter som är associerade med bilderna, och om en beständig cookie saknades måste du också svara på en säkerhetsfråga. Detta fungerar nästan lika bra som tvåfaktorautentisering.

Båda är föremål för kapning av sessioner. För att hantera det kan du försöka använda ett webbläsarfingeravtryck utöver det för en cookie. En något anständig tillnärmning utan att gå in i besväret med något som Panopticlick skulle vara att bara använda IP-adressen, User Agent-strängen, en SSL-cookie och en tidsgräns på tio minuter.

Att kräva lösenordsrotation över tid kan hjälpa till att bekämpa nätfiske och nyckelloggare, men de skadar åter lösenordskomplexiteten. Dessa hjälper bara i det avseendet om angriparen har en lång fördröjning innan han försöker utföra åtkomsten. Det är här extra säkerhetsfrågor för okända datorer kan hjälpa till.

Du kan också överväga klient-SSL-certifikat, även om de inte själva kanske är lösenordsskyddade (och du kan inte genomdriva det), vilket innebär att en förlorad dator är ett stort problem.

Jag rekommenderar flera lager . En säker lösenfras är ett lager, det andra lagret (behövs bara om webbläsarens fingeravtryck inte matchar) är antingen externt (två faktorer), en slumpmässigt placerad känd bildsekvens att klicka eller ett klient-SSL-certifikat (som skulle lindra behovet för fingeravtryck).

Varför hanterar du inte bara leetspeak-ord som vanliga? I dina exempel säger du att du accepterar GoodPassword4! , eftersom det har mer än ett ord (och symboler och siffror). Så den implicita regeln som du verkar tillämpa här är:

"Om du måste använda ordboksord, använd mer än bara ett (och även lite symbol och nummer)".

Jag antar att det är en regel som faktiskt är lätt att förstå och acceptera ur användarens synvinkel. Men än att det skulle vara ganska irriterande att få G00dP4ssword4! eller B4DTr0ub4dor1! avvisad enligt den regeln.

Så, nej, du borde inte tillåta "leetspeak" ordboksord i sig, men behandla dem som vanliga ordboksord.

Vad sägs om en mellanväg?

De regler du anger säger i grunden antingen långa eller hårda utan mellanliggande mark.

Vad sägs om ett graderat system: Tilldela en viss komplexitet per karaktär och en viss multiplikator för de olika hårda funktionerna. Om antalet är tillräckligt högt accepterar du lösenordet. Således om du accepterar i princip något på 16 tecken skulle du acceptera 15 med en hård funktion.

Be din mormor (eller någon mormor inom gångavstånd) att definiera ett lösenord. Hon måste följa de strikta lösenordsreglerna (som du har skrivit ut för henne), men hon får inte prata med dig. Och det borde inte ta "för lång tid".

Berätta också för henne att hon kommer att behöva lösenordet de följande dagarna / veckorna (för att använda din webbtjänst), så att hon måste se till att kom ihåg det (förmodligen genom att skriva ner det).

(Kom ihåg att när du ser din mormor räcka efter ett papper, kan du be henne att inte skriva ner det och klistra det i kylen - du kommer inte att kunna berätta det för dina riktiga användare. Om du inte skriver en lista med regler på registreringsformuläret, som "skriv inte ditt lösenord i kylen" och "nej, inte heller på din bildskärm".)

Hur gick det nu? Om svaret är "inte så bra" (gav hon upp efter 5 minuter och frågade om du redan har ätit eftersom det också räknas som "inte så bra"), kan det vara en stark indikation på att dina lösenordsregler är för starka .

Jag instämmer i allmänhet med svaret som fick de flesta uppröstningarna och med flera av kommentarerna:

En grundregel, som är minsta längd, som 7 eller 12 eller 15 eller vad som helst. Ja, det gör att människor kan använda "aaaaaa" som lösenord men åtminstone kommer det inte att skrivas i klartext där andra kommer att se det för att de kommer ihåg det. Alla dessa regler gör förmodligen ingenting annat än att skada (ja, mestadels). Oavsett hur många miljoner ordboksord du utesluter, kommer någon att använda ett ord du inte har tänkt på (ja, inte "du" tekniskt, du kommer antagligen bara att få den listan någonstans). Och av någon anledning kommer en mänsklig angripare att lyckas eftersom rätt lösenord "Mugwump" eller "Smellfungus" är det första han försökte.

När det gäller de "du måste använda tre versaler, gemener, siffror och speciella tecken", kommer det bara att få många att skriva ABCabc012! @ # på ett papper eftersom de kan kommer inte ihåg det. (Om det inte finns något kylskåp i området, en bekväm vägg gör det också, se den här artikeln.)

Och för att vara rättvis är människor som förstår hur viktigt det är människor de kommer inte heller att kunna komma ihåg dessa (konstgjorda) lösenord och de kommer att bli irriterade. De flesta vanliga datoranvändare ("skriv ut Internet" -typ av användare) kommer att bli irriterade ändå (även det enda faktumet att ett lösenord är nödvändigt är "irriterande" för många, trots allt borde datorer kunna identifiera användaren magiskt 2015 ).

Utan dessa komplicerade regler har du åtminstone en chans att många faktiskt kommer ihåg sitt lösenord.

Men som vissa tjänster gör, ökar säkerheten om något fishy upptäcks kan vara en idé. Du blockerar redan autentisering helt efter några misslyckade försök, vilket är bra. Du kanske tänker på steg däremellan, till exempel efter ett eller två misslyckade försök kan du be om en captcha. Dessutom kan en specifik klient som fortsätter att försöka logga in (även om inloggningen redan är blockerad) automatiskt blockeras under en dag (på en lägre nivå, kanske till och med av en brandvägg).

Jag gillar inte lösenordsregler som har många, "det här, men inte det, en av dessa, men inte för många av dessa" regler.

Är jag för svår?

Jag tror det, här är varför. Jag använder 1Password. Det genererar slumpmässiga lösenord för mig. De ser ut så här:

  luaD / fcr61nt7A% NxBCRNeTtVL7uuAqmL5_j&cm1qwtlOjJsQor) 9nM1% zl2  

Vissa webbplatser har avvisat sådana lösenord. Varför? Godtyckliga regler.

Innan detta hade jag inte övervägt ett system som är det motsatta: snarare än att be mig att skapa ett lösenord, tilldelar systemet mig ett som uppfyller dess regler. Lösenordet hamnar alltid på papper eller klistras in i någon fil av personen, men det är unikt och inte i en ordlista.

IAM inom Amazon Web Services gör ganska mycket detta, så denna idé har till och med några tidigare konst där ute.

Här är en brute-force-lösning på problemet med brute force-lösenordssprickning: ägna några datorer till att faktiskt försöka knäcka lösenord med samma (få) sprickverktyg som angriparna använder. När ett lösenord har knäckt framgångsrikt, skicka ett mejl artigt och informera användaren om att deras lösenord upptäcktes för svagt och kräver att användaren byter lösenord.

Återigen är jag ingen expert på informationssäkerhet på något sätt, men kanske kan du bara uppmuntra dina användare att använda LastPass eller Keeper för att generera och lagra stora (riktigt) slumpmässiga lösenord för dem och lagra dem på ett säkert sätt valv? Och att använda tvåfaktorautentisering också.

Jag inser att LastPass nyligen hackades, men användare som valde långa, säkra LastPass-lösenord bör fortfarande vara säkra från att öppna valvet. Användare som valde ett svagt lösenord som huvudlösenord kan ändå inte få hjälp.

Naturligtvis är det inte den bästa planen, men det borde åtminstone sätta dina användare på rätt spår. Det finns mycket inkonsekvens i säkerhet mellan webbplatser. Jag förstår det (till exempel tillåter min bank en maximal lösenordslängd på 16 tecken, men mitt reddit-lösenord är 100 tecken). Men 16 slumpmässiga tecken är fortfarande bättre än att behöva skriva ner lösenordet eftersom du inte kommer ihåg det.