Lösenordspolicy

typiska komponenter i en lösenordspolicy inkluderar:

lösenordslängd och formationEdit

Se även: lösenordsstyrka

många policyer kräver en minsta lösenordslängd. Åtta tecken är typiska men kanske inte lämpliga. Längre lösenord är i allmänhet säkrare, men vissa system har en maximal längd för kompatibilitet med äldre system.

vissa policyer föreslår eller ställer krav på vilken typ av lösenord en användare kan välja, till exempel:

  • användning av både versaler och gemener (skiftlägeskänslighet)
  • införande av en eller flera numeriska siffror
  • införande av specialtecken, såsom @, #, $
  • förbud mot ord som finns i en lösenordsblocklista
  • förbud mot ord som finns i användarens personliga information
  • förbud mot användning av företagsnamn eller en förkortning
  • förbud mot lösenord som matchar formatet för kalenderdatum, nummerskyltnummer, telefonnummer eller andra vanliga nummer

andra system skapar ett lösenord som är initial lösenord för användaren; men kräver då att ändra den till en av sina egna val inom ett kort intervall.

Lösenordsblock listEdit

Lösenordsblocklistor är listor över lösenord som alltid blockeras från användning. Blocklistor innehåller lösenord konstruerade av teckenkombinationer som annars uppfyller företagets policy, men bör inte längre användas eftersom de har bedömts osäkra av en eller flera skäl, till exempel att lätt gissas, följa ett gemensamt mönster eller offentliggörande från tidigare dataintrång. Vanliga exempel är Password1, Qwerty123 eller Qaz123wsx.

Lösenordsvaraktighetredigera

vissa policyer kräver att användare ändrar lösenord regelbundet, ofta var 90: E eller 180: e dag. Fördelen med lösenordets utgång är dock diskutabel. System som implementerar sådana policyer hindrar ibland användare från att välja ett lösenord för nära ett tidigare val.

denna policy kan ofta slå tillbaka. Vissa användare har svårt att utforma ”bra” lösenord som också är lätta att komma ihåg, så om människor måste välja många lösenord eftersom de måste byta dem ofta, slutar de använda mycket svagare lösenord; policyn uppmuntrar också användare att skriva ner lösenord. Om principen hindrar en användare från att upprepa ett nytt lösenord kräver det också att det finns en databas med allas senaste lösenord (eller deras hashar) istället för att de gamla raderas från minnet. Slutligen kan användare ändra sitt lösenord upprepade gånger inom några minuter och sedan byta tillbaka till det de verkligen vill använda, kringgå lösenordsändringspolicyn helt och hållet.

de mänskliga aspekterna av lösenord måste också beaktas. Till skillnad från datorer kan mänskliga användare inte ta bort ett minne och ersätta det med ett annat. Följaktligen är ofta byte av ett memorerat lösenord en belastning på det mänskliga minnet, och de flesta användare använder sig av att välja ett lösenord som är relativt lätt att gissa (se Lösenordsutmattning). Användare rekommenderas ofta att använda mnemonic-enheter för att komma ihåg komplexa lösenord. Men om lösenordet måste ändras upprepade gånger är mnemonics värdelösa eftersom användaren inte kommer ihåg vilken mnemonic som ska användas. Dessutom gör användningen av mnemonics (vilket leder till lösenord som ”2bornot2b”) lösenordet lättare att gissa.

Administrationsfaktorer kan också vara ett problem. Användare har ibland äldre enheter som kräver ett lösenord som användes innan lösenordet löpte ut. För att hantera dessa äldre enheter kan användare behöva använda sig av att skriva ner alla gamla lösenord om de behöver logga in på en äldre enhet.

att kräva ett mycket starkt lösenord och inte kräva att det ändras är ofta bättre. Detta tillvägagångssätt har dock en stor nackdel: om en obehörig person förvärvar ett lösenord och använder det utan att upptäckas kan den personen ha tillgång på obestämd tid.

det är nödvändigt att väga dessa faktorer: sannolikheten för att någon gissar ett lösenord eftersom det är svagt, jämfört med sannolikheten för att någon lyckas stjäla, eller på annat sätt förvärva utan att gissa, ett starkare lösenord.

Bruce Schneier hävdar att” nästan allt som kan komma ihåg kan knäckas ” och rekommenderar ett schema som använder lösenord som inte kommer att visas i några ordböcker.

Sanktionedit

Lösenordspolicyer kan innehålla progressiva sanktioner som börjar med varningar och slutar med eventuell förlust av datorbehörighet eller uppsägning av jobb. Där sekretess är lagstadgad, t. ex. med sekretessbelagd information kan ett brott mot lösenordspolitiken vara ett brott. Vissa anser att en övertygande förklaring av vikten av säkerhet är effektivare än hot om sanktioner.

Lämna ett svar

Din e-postadress kommer inte publiceras.