Skydda dina lösenord i .Net
Förord
Vikten av att skydda lösenorden är något det flesta har hört talas om förut. De som tar säkerheten på allvar skyddar sina lösenord. Denna artikel handlar dock inte om att skydda sina personliga lösenord utan om att skydda lösenorden till alla som har en användaridentitet i ditt system eller de system du har utvecklat. Hur långt man vill gå för att skydda lösenorden beror givetvis på hur viktigt det är att lösenorden är och förblir skyddade. När pengar är involverade är det vanligt med lite högre säkerhetskrav, men det kan också finnas andra situationer när en högre säkerhet är att föredra.
Var skall lösenorden skyddas?
Lösenorden behöver skyddas på klientsidan, på väg mellan klient och server, samt på serversidan. Att skydda lösenorden på klientsidan och på väg mellan klient och server är oftast rätt så enkelt att lösa med html/http-baserade lösningar: Se till att textboxen som användaren använder för lösenord har typen password (så att bokstäverna inte syns när de skrivs in), använd post-metoden (så lösenordet inte syns i QueryString) och kryptera överförningen mellan klient och server (https). Denna artikel handlar om att skydda lösenorden på serversidan.För att lösenord skall kunna användas för autentisering/inloggning måste lösenordet sparas någonstans. Man måste ju kunna jämföra det lösenord som en användare har skrivit in med det korrekta lösenordet när en inloggning skall ske. En viktig säkerhetsåtgärd är att skydda det korrekta lösenordet som finns sparat på servern.
Nu funderar du säkert på varför lösenorden behöver skyddas på servern? Är inte servern en skyddad plats? Både ja och nej. Det är möjligt att den servern där din applikation ligger är bra skyddad mot intrång utifrån. Även om detta är fallet borde lösenorden skyddas på serversidan. Orsaken till detta är att den egna personalen är den näst största säkerhetsrisken idag, endast internet utgör en större säkerhetsrisk. Mänskliga fel är en vanligare orsak till säkerhetsincidenter än tekniska fel. Utöver detta har det mer en en gång inträffat att den egna personalen ”hämnats” på företaget (eller vissa personer på företaget) och medvetet ställt till med problem.
Lösenord i ASP.NET
I ASP.NET finns det ett bra inbyggt stöd för hantering av inloggning och därmed också för hantering av lösenord. Ett standardsätt att spara lösenorden i ASP.NET är att infoga en user-tagg i web.config-filen. I denna tagg skall användarnamn och lösenord skrivas in på följande sätt:
Problemet med detta är att alla som får tag på web.config-filen omedelbart kan se vilket lösenord en användare har. Men för att använda det inbyggda sättet att spara lösenord måste man ju spara lösenordet i web.config-filen. Tänkte man inte på säkerheten när man tog fram lösenordshanteringen? Svaret är att man visst tänkte på säkerheten.
I web.config kan man specificera på vilket format man skrivit in lösenordet. I exemplet ovan är lösenordet inskrivet i klartext. Det finns dock två andra tillåtna förmat: sha1 och md5. Detta är namn på två olika Hash-algoritmer som finns implementerade som metoder i .NET framework.
En Hash-metod är en metod som kastar om och byter ut tecken i en teckenföljd och på så sätt göra teckenföljden oläsbar. I en säker Hash-metod skall det vara mycket svårt att reversera processen eller att gissa sig till hur den orginala teckenföljden såg ut baserat på den Hashade teckenföljden. För att det skall bli lättare att associera funktionaliteten med ordet kan det vara trevligt att veta att Hash betyder pyttipanna i USA!
Om man använder Hash-metoden Sha1 på lösenordet bil blir resultatet: 525298336F32B2571F53CE0A7C9BFC8B0FB4E709. Det man sparar i sin web.config-fil är alltså 525298336F32B2571F53CE0A7C9BFC8B0FB4E709, dvs en oläsbar version av lösenordet. Nu kommer alltså vår user-tag att se ut så här:
Hur kan man då Hasha sina lösenord? Det finns inbyggt funktionalitet för detta i .NET framework i klassen FormsAuthentication som finns i namespacet System.Web.Security. Metoden används på följande sätt:
C#
string pwd = FormsAuthentication.HashPasswordForStoringInConfigFile("bil","sha1");
VB.NET
Dim pwd As String = FormsAuthentication.HashPasswordForStoringInConfigFile("bil", "sha1")
För att inloggningen skall fungera måste man även tala om för ASP.NET att lösenordet är Hashat. Detta skrivs in i Credentials-taggen. Taggarna i web.config skall nu se ut på detta viset:
Detta behövs för att inloggningen skall fungera. Nu kommer nämligen inloggningsmetoderna att använda samma Hash-metod som den du använde när du gjorde lösenordet oläsbart. Man jämför alltså en Hashad version av det korrekta lösenordet med en Hashad version av inmatat lösenord istället för att jämföra lösenorden direkt.
Vad är då fördelen? Om någon kommer åt web.config så ser de inte lösenordet. Även om de har den oläsbara versionen av lösenordet är det inte lätt att reversera processen, dvs ta reda på att 525298336F32B2571F53CE0A7C9BFC8B0FB4E709 betyder bil. När man loggar in som Olle så måste man skriva in bil. Om man skulle skriva in 525298336F32B2571F53CE0A7C9BFC8B0FB4E709 kommer man inte bli inloggad. Lösenordet är alltså skyddat!
Lösenord i databasen
I dagens applikationer i den stora, verkliga världen använder man oftast databaser för att spara lösenord. Tillvägagångssättet för att skydda lösenorden i databasen är detsamma som tidigare. Man sparar det Hashade lösenordet i databasen (trots det något långa men mycket beskrivande metodnamnet går det att använda metoden till att Hasha ett lösenord som inte skall sparas i web.config-filen :). Vid inloggningen jämför man sedan med ett Hashat värde av det lösenord som användaren har skrivit in.När lösenorden sparas i databasen kan man få en bonuseffekt: Om man har en databas som inte skiljer mellan små och stora bokstäver och sparar lösenordet i klartext i databasen så kan i detta fallet Olle logga in med lösenorden bil,Bil,bIl,biL,BIl,BiL,bIL eller BIL. Det spelar ingen roll vilken variant av ordet bil som har sparats i databasen eller vilken variant som skrivits in av användaren. Men om man tittar på det Hashade värdet av lösenordet är det annorlunda. Det Hashade värdet av bokstaven a är (med Sha1) :
86F7E437FAA5A7FCE15D1DDCB9EAEAEA377667B8
medans det Hashade värdet av bokstaven A är (fortfarande med Sha1 :) :
6DCD4CE23D88E2EE9568BA546C007C63D9131C1B
Man får alltså en inloggning som endast accepterar lösenord som är helt korrekta och alltså skiljer på stora och små bokstäver.
Ännu bättre skydd
Är lösenorden skyddade till 100% när de är hashade? Tyvärr. Ett 100%-igt skydd är omöjligt att åstadkomma. Finns det något sätt att ta reda på det ”verkliga” lösenordet utifrån ett hashat värde? Tyvärr, ja. Detta gäller trots det faktum att det inte går att reversera metoden som användes för att hasha värdet.Om man bygger upp en lösenordslista där man sparar par av värden bestående av lösenordet och det hashade värdet för lösenordet så kan man hitta vilket ord som har hashats. Detta kräver dock att man har exakt (inkl stora och små bokstäver) det lösenord som en användare har använt sig av i sin lista. Om användaren har ett bra lösenord är det inte så sannolikt att detta lösenord finns i lösenordslistan. Men för att göra det svårare att hitta lösenordet på detta sätt kan man ”salta” lösenordet innan det sparas. Att salta ett lösenord innebär att man innan lösenordet hashas lägger ihop lösenordet med en slumpmässigt valt sträng, gärna olika strängar för olika användare. Ett salt skulle kunna se ut så här: EG&324sj. Lägg alltså ihop saltet med lösenordet innan det hashas och kom ihåg att använda saltet när du skall hasha det lösenord som användaren matat in, annars ger ju jämförelsen ett felaktigt svar.
Detta ger ett bättre skydd eftersom det är mycket osannolikt att lösenordslistan innehåller lösenordet bilEG&324sj. Om man har tillgång till saltet, dvs vet att användaren Olle har salt-värde EG&324sj så blir det inte så mycket lättare att ta reda på lösenordet. Då måste man bygga upp en lista som innehåller alla de vanliga lösenorden + EG&324sj samt dess hashade motsvarighet. Om alla användare har olika saltvärden måste man alltså göra helt olika listor för alla lösenorden för att kunna använda listan till att hitta rätt lösenord. Att göra sådana listor är en uppgift som tar mycket stora resurser i anspråk och även om man gör detta finns inga garantier för att man lyckas: Användaren kan ju ha ett ovanligt lösenord.
En nackdel med Hashade lösenord
En nackdel med Hashade lösenord är att man inte kan erbjuda en service som många efterfrågar idag när man kan logga in på så många olika webbplatser på Internet. Har du någon gång bett att få ditt lösenord skickat till dig per e-post? I så fall är du inte ensam. Det är viktigt att tänka på att det inte är säkert att skicka lösenordet till en användare per e-post. Om det är viktigt med hög säkerhet bör lösenordet i så fall krypteras så att endast mottagaren kan läsa lösenordet. Vilket lösenord skall man då skicka? Det går ju inte att få fram lösenordet, endast det hashade värdet har sparats i databasen. Det man kan göra är att automatgenerera ett nytt lösenord och skicka detta med e-post (krypterat) eller med vanlig post till den användare som glömt bort sitt gamla lösenord. Nackdelen för användaren är att han/hon får ett lösenord som kan vara svårt att minnas. Å andra sidan kan man ju tillåta användarna att byta sina lösenord vilket borde lösa detta problem.
Hashade lösenord i andra språk
Principerna för lösenordshantering är desamma för alla språk. Detta innebär att man lika väl kan hasha lösenorden i VBScript, Java, C, Perl och alla andra språk som finns tillgängliga. Om du väljer att hasha lösenorden är det viktigt vilken metod du använder. Sha1 och MD5 bedöms idag vara mycket säkra och finns implementerade i många olika språk. Det finns andra hash-metoder men dessa är antigen relativt färska (dvs inte tillräckligt beprövade) eller mindre säkra än Sha1 och MD5. Eftersom Sha1 ger en längre hash-sträng än MD5 rekommenderar jag att du i första hand väljer Sha1.
Resurser
- RSA security (information om kryptering och Hashning)
- HashPasswordForStoringInConfigFile-metoden
Lycka till!
Herbjörn
Elias Hedberg
Hej Herbjörn! "Nackdelen" att man inte kan skicka det ursprungliga lösenordet till användaren kan lätt överkommas genom att man, som du säger, skapar ett nytt lösenord. Däremot ska man inte tillåta användaren att byta lösenordet – man ska _se_till_ att de gör det. Då slår man två frågor i en smäll: användaren kan välja ett lösenord efter eget huvud (vilket kan ha både för- och nackdelar) och ingen kan använda sig av det lösenord som skickades öppet i mejlet. Två vanliga sätt att göra det: 1) Skicka nya lösenordet i klartext i ett mejl och be användaren byta när de loggat in (eller visa byt-lösenord-sidan direkt och släpp dem inte vidare förrän de bytt). 2) Skicka en engångslänk till en sida där de kan byta sitt lösenord. Med vänliga hälsningar Elias Hedberg eliashedberg@gmail.com