Skrivet av Cyne:
Hur funkar det här med att "knäcka lösenord"? Går det att avkryptera så man får ut lösenordet i klartext så man vet att det är korrekt, eller måste man testa lösenordet mot en tjänst? Jag tänker att om det bara är en begränsning på säg max 1 försök i sekunden hos en tjänst så tar det ju miljoner år att knäcka även ganska enkla lösenord.
Om man bygger ett IT-system enligt vad som varit minsta rimliga norm säkerhetsmässigt i flera årtionden så lagras inte lösenorden i sig i klartext. D.v.s. du kan inte öppna en databastabell någonstans och se att kalle har 12345
som lösenord.
Istället ser du i databastabellen långa komplicerade hash, som t.ex. $2a$12$LMoyva9ox6e4lwJg9ZiyN.JnEOekg3fncqqtDEezL0uiXajKhYk4u
. Det går inte att "räkna baklänges" från ett sånt här hash för att komma tillbaka till lösenordet, men man kan gör att, givet ett lösenord, kolla om lösenordet stämmer med hashet.
Det man gör när man knäcker ett lösenord är att man helt enkelt provar en massa möjliga lösenord mot lösenordhashet i fråga tills man hittar ett lösenord som passar. (Grafikkort är väldigt bra på att göra den här typen av upprepade enklade beräkningar, därför används de för det här syftet.)
Ju längre och komplicerat och ju mindre oförutsätbart lösenordet är, desto svårare är det att gissa. Därav tabellen i artikeln. Även om det också är viktigt att undvika ord och annat som är lätta att gissa. Tabellen utgår från fullständigt slumpmässigt genererade lösenord.
När du loggar in på en webbsida skickar du ditt användarnamn och lösenord till webbsidan. Webbsidan kollar sedan om lösenordet matchar hashet i databasen och släpper in dig. Allt detta utan att någonsin lagra lösenordet.
I väldesignade system är de här lösenordshashen ändå nedlåsta i någon databas någonstans som ingen buse kommer åt, så det är att se som ett sista försvar för att skydda användarens lösenord. Eftersom många använder samma lösenord på flera olika siter så är det ju guld att veta vilket lösenord användaren använder på site A, för att sedan prova samma på site B.
(Sedan finns det så klart mindre väldesignade system, som t.ex. IPMI, som skickar ett lösenordshash till användaren innan inloggning. Tanken IPMIs utvecklare hade där var att de ville förebygga att någon kan låtsas vara en IPMI-server och lura till sig ett lösenord från en användare, men konsekvensen blir istället att en IPMI-server lämnar ut lösenordshash till vem som helst som frågar. Inte helt optimalt, då det öppnar för en attack genom lösenordsknäckning.)
Det bästa du kan göra som slutanvändare är att:
- Använd långa och komplicerade lösenord som är svåra att knäcka eller gissa
- Använd inte samma lösenord på fler än en site
- Använd tvåfaktorsinloggning där det är möjligt
Bästa sättet att ha långa komplicerade lösenord som är unika för varje site är att använda en lösenordshanterare, som du i sin tur låser med ett starkt lösenord och tvåfaktorsinloggning. Det finns många att välja på. Själv använder jag 1Password som jag är nöjd med. Den som får dåliga vibbar av att lagra sina lösenord i molnet kan t.ex. kolla på KeePass istället, som använder en lokal krypterad fil för att lagra lösenorden.
Till sist, den som tänkt efter när hen läst ovan inser också att varje gång du loggar in på en site skickar du ditt lösenordet till den siten. Detta är ett krav för att man ska kunna testa hashet. Det finns ju dock inget som säger att webbsidorna du loggar in på inte sparar eller loggar lösenorden du loggar in med, t.ex. om de blivit hackade. Därför är det viktigt att använda unika lösenord på alla siter, helt oavsett vilken säkerhet siten utger sig för att använda.