Lösenord 2/2

I del 1 gick jag igenom grundläggande koncept om lösenord. Läs det först. Här kommer mer detaljer som komplement till del 1.

Hashalgoritmer

  • MD5 – Ger en 128-bits hashsumma. Summan skrivs oftast ut på hex-format där varje tecken representerar 4 bitar. Alltså skrivs summan som 128/4 = 32 tecken. Exempel 0d107d09f5bbe40cade3de5c71e9e9b7
  • SHA-1 – Liknar MD5 men ger en summa på 160 bitar = 40 hex-tecken. Exempel b7a875fc1ea228b9061041b7cec4bd3c52ab3ce3
  • SHA-256 – Som SHA-1 fast med 256 bitars summa = 64 hex-tecken. Exempel 1c8bfe8f801d79745c4631d09fff36c82aa37fc4cce4fc946683d7b336b63032. SHA-256 är en variant av SHA-2. Andra varianter av SHA-2 ger 224, 384 och 512 bitars output.

Rainbow Tables

En regnbågstabell, Rainbow Table, är en slags förberäknad lista av hashar och deras motsvarande lösenord. En ren lista med en rad för varje hash->lösenord skulle ta för stor plats på disken. Att låta datorn räkna ut alla kombinationer i realtid tar inget lagringsutrymme alls men tar i stället mycket beräkningskraft av datorns CPU. Rainbow Tables är ett listigt sätt att minska storleken på listan genom att låta datorns CPU göra vissa beräkningar under uppslagningen. En kompromiss mellan lagringsutrymme och datorkraft.
Själva förberäkningen av en regnbågstabell tar enorm CPU-kraft. Men detta görs bara en gång, när väl listan är beräknad kan den användas om och om igen. Det finns flera projekt där folk kopplar ihop sina datorer över internet för att tillsammans beräkna nya regnbågstabeller för olika algoritmer och varianter av tecken i lösenorden. Förberäknade listor finns också till försäljning.

Salt

För att besegra förberäknade listor (t.ex. Rainbow Tables) kan man använda en Salt, en modifiering av hashalgoritmen. Då måste en separat regnbågstabell beräknas för varje salt, vilket i dagsläget knappast är genomförbart. De regnbågstabeller som finns tillgängliga attackerar endast algoritmer utan salt.

Exempel

Låt säga att lösenordet (letmein) sparas som en MD5-hash. Istället för att bara hasha lösenordet slumpar datorn först fram ett tal mellan 0 och 255 (8 bitar), som blir våran salt (kan skrivas som två hex-tecken). Låt säga att slumptalet blir 255, då blir hextecknen ”FF”. Sen sätts FF ihop med lösenordet och hashas. Salt sparas i klartext följt av den hashade strängen. T.ex. kan tecknet $ användas för att skilja salt och hash åt.

md5($salt.$pass)

Om saltet består av 8 bitar behöver man göra en separat regnbågstabell för varje salt, 2^8 = 256 stycken. Består saltet istället av 32 bitar behövs 2^32 (c:a 4 miljarder) regnbågstabeller, vilket blir så mycket data att det inte går att spara på en hårddisk ens om man hade CPU-kraft för att skapa alla dessa tabeller. En regnbågsattack är alltså omöjlig att genomföra bara man väljer ett tillräckligt långt salt.

Varianter på algoritmer

Följande varianter är vanliga för att lagra inloggningslösenord till olika webbtjänster. Språket är då ofta PHP och där används operatorn . för att lägga ihop två strängar. $pass är lösenordssträngen och $salt är den slumpade salt-strängen.

  • MD5 – kallas även raw MD5, osaltad.
  • md5($pass.$salt) – MD5 av lösenordet + salt.
  • md5($salt.$pass) – MD5 av salt + lösenord (saltet läggs före lösenordet istället för efter).
  • md5(md5($pass)) – dubbel MD5, osaltad.
  • md5(md5($pass).$salt) – Variant av dubbel MD5 med salt efter första hashningen.
Samma varianter kan även genomföras med MD5 utbytt mot SHA-1 eller någon av SHA-2-algoritmerna.

Unix crypt(3)

I den ursprungliga implementationen av Unix crypt() användes en variant av DES. Det är egentligen ingen hashalgoritm utan en algoritm för vanlig symmetrisk kryptering. DES modifierades för att skapa en slags envägshashar (se sektionen crypt(3) här för detaljer om hur DES används för att skapa en hash med fast längd och som inte går att köra ”baklänges” för att få ut lösenordet på matematisk väg).

DES har använts sedan 1970-talet och redan då kände man till den teoretiska möjligheten att attackera lösenord med hjälp av förberäknade listor. Därför hade redan den ursprungliga DES-implementationen av crypt(3) stöd för salt. Saltet lagrades direkt före hashen utan skiljetecken. DES stödde inte lösenord som var längre en 8 tecken. Sedan kom en variant för Unix-dialekten BSD som baserades på MD5. Den känns igen på att lösenordet sparas med prefixet $1$. Sedan följer saltet följt av ännu ett $-tecken och till sist själva hashen. Lösenordet och saltet hashas med MD5 tusentals gånger i ett komplext mönster för att öka CPU-kraften som krävs för att göra en brute-force attack.

Algoritm, salt och hash

Varianter av crypt(3) och deras respektive prefix:

  • $1$ – MD5 baserad variant (se ovan). Ex: $1$Z9LPJXYf$qL.E5.lbOvF0V5Nmnso5M0
  • $2$, $2a$ – Blowfish-baserade varianter.
  • $3$ – Windowsalgoritm. Obs, lätt att knäcka. Använd ej! Denna algoritm delar upp lösenordet i två delar om max 7 tecken som var och en kan attackeras separat. Dessutom översätts alla små bokstäver till stora bokstäver vilket minskar antalet kombinationer som behövs för en brute force.
  • $5$, $6$ – SHA-256 respektive SHA-512 baserade varianter (liknande $1$, med vissa förbättringar) Ex: $6$uCm9vgHD$l52huIkoheMH4owuzrPSs5px0TYAerOjP96hm8VufS7I6Ygh/76p.azTiqcV8jJkp1XSEsKWXsfN.GNA.vhky0

GPU

Datorns vanliga CPU är skapad för att kunna köra många olika typer av program. Hårdvaran utnyttjas inte särskilt effektivt när en CPU används för att testa alla kombinationer av lösenord. S.k. brute force. Dagens datorer har ofta kraftfulla grafikkort och på dessa sitter en annan typ av processorer, grafikprocessorer, GPU. Dessa är specialiserade på att göra beräkningar på stora datamängder (vilket behövs för datorgrafik). Moderna grafikkort kan även användas för att köra egen mjukvara på och det har visat sig att de är betydligt snabbare på brute force än en generell CPU. Ofta en faktor 10 – 100 ggr snabbare än CPU:n.

Verktyg

Här kommer en lista på program som kan användas för att testa lösenord. Meningen är inte att du ska försöka knäcka någon annans lösenord med dessa program utan endast testa att dina egna lösenord är tillräckligt bra.

  • John the Ripper – Ett av de snabbaste programmen som kör på CPU:n. Har algoritmerna implementerade i handskriven assembler. Stödjer många plattformar.
  • oclHashCat – Använder GPU. Endast NVidia- och ATI-kort.
  • RainbowCrack – Använder Rainbow Tables (endast algoritmer utan salt, t.ex. Windowslösenord och olika osaltade webbvarianter)
  • Free Rainbow Tables – Projekt för att skapa fria regnbågstabeller med hjälp av distribuerad datorkraft. Du kan ansluta din dator via internet och låta den hjälpa till att räkna ut tabellerna.

Håll i dina hashar

Hur får då attackeraren tag på dina lösenordshashar? Det finns olika sätt. Här är några:

  • Fysisk tillgång till datorn – Om någon har fysisk tillgång till din dator kan han/hon boota om datorn och starta med en live-skiva/live-sticka. Sedan kan diskarna monteras och lösenordshasharna kopieras. Oavsett om datorn kör Windows eller Linux. Skydda dig genom att inte låta någon obehörig få fysisk tillgång till din server. Dessutom kan du ställa in lösenord i BIOS och se till att det inte går att boota från CD eller USB-sticka.
  • SQL injection – En webbsida lagrar ofta lösenordshasharna i en SQL-databas. Genom att skräddarsy en URL kan attackeraren få webbservern att exekvera godtycklig SQL-fråga. Inklusive en fråga som listar tabellen med lösenordshasharna (SELECT * FROM users). Den felaktiga URL:en innehåller oftast ett oterminerat ‘-tecken. Skydda dig mot SQL-injections genom att ”tvätta bort” otillåtna tecken från URL:en innan en SQL-fråga görs.
  • Buffer overflow – Någon kan också få tillgång till din server om det finns något säkerhetshål i någon av de tjänster som körs. Det vanligaste problemet är en s.k. buffer overflow, det innebär att någon skickar för lång input till någon tjänst vilket skriver över stacken i processen som hanterar tjänsten. Detta kan i bästa fall krasha processen (denial of service) och i värsta fall leda till att attackeraren kan exekvera godtyckliga kommandon (t.ex. ett kommando som ger ett root-shell vilket sen kan användas för att läsa ut lösenordshasharna). Skydda dig genom att stänga av alla tjänster som inte används. Se dessutom till att installera säkerhetsuppdateringar direkt när de kommer ut. En brandvägg kan också hjälpa i vissa fall, om den är korrekt inställd. Vissa plattformar tillåter dessutom en inställning som kallas ”non executable stack”. Om den inställningen används förhindras processen att exekvera kod från stacken vilket gör att godtyckliga kommandon inte kan exekveras av en buffer overflow attack. Finns inte stöd för nonexecutable stack kan istället flaggan -fstack-protector ges till GCC vid kompileringen. Då lägger GCC automatiskt in kod som försöker skydda mot buffer overflows.
  • Randomisering – För att ytterligare skydda sig mot buffer overflows kan man också ställa in så att adresserna till stacken, heapen, libc, miljövariabler med mera slumpas varje gång en process startas. Det blir då svårare att utnyttja en buffer overflow eftersom en attack kräver att en ungefärlig adress, till någon minnesrymd där koden som ska exekveras har planterats, kan gissas.
  • Lokala användare – En person som har tillgång till ett användarkonto (s.k. shellkonto) på servern har mycket större möjligheter att hitta säkerhetshål som kan leda till att hasharna kan läsas ut. Ge endast shellkonto till användare du litar på.
  • Jail – Ett generellt sätt att skydda en serverprocess är att låta den exekvera inuti ett fängelse, jail. Då begränsas serverprocessen till att endast få tillgång filerna inuti jailet. Även om processen blir manipulerad till att exekvera godtyckliga kommandon kan den ändå inte läsa ut lösenordshasharna. Du kan till och med placera falska hashar inuti jailet. Till många Unixliknande system, som Linux, finns dessutom utökade säkerhetsmodeller där inställningar kan göras för varje serverprocess där man talar om vilka filer processen ska få tillgång att läsa och/eller skriva till.
  • Uppgradera även kerneln – Då och då upptäcks säkerhetsproblem i själva Linuxkerneln. Automatiska säkerhetsuppgraderingar brukar *inte* boota om servern efter en uppgradering av kerneln. Se till att hålla kerneln uppdaterad och boota om efter en uppdatering. De flesta attacker kräver shellkonto (local) men en del går även att utnyttja på distans (remote).
Skulle hasharna ändå komma på vift är det som sagt viktigt att de är saltade, består av minst 8 tecken, helst 9, med stora och små bokstäver blandade och minst en siffra och minst ett specialtecken. Salt förhindrar en rainbow table attack. Längden på lösenordet i kombination med många olika typer av tecken gör att en brute force tar lång tid.
Advertisements

Om albertveli

Grävande programmerare.
Det här inlägget postades i Linux/DIY, Säkerhet. Bokmärk permalänken.

4 kommentarer till Lösenord 2/2

  1. Moggen skriver:

    Och för att uppnå lite mer säkerhet:
    http://codahale.com/how-to-safely-store-a-password/

    • Albert skriver:

      Intressant. Bcrypt använder samma idé som Poul-Henning Kamp hade när han designade $1$-algoritmen till BSD. Kamp körde MD5 tusentals ggr för att öka brute force tiden. Bcrypt verkar göra samma sak, fast med blowfish. Man kan göra det själv också genom att t.ex. anropa sha-512 tiotusen ggr på lösenordet (+salt).

    • Albert skriver:

      Man kan också notera att bcrypt är algoritmen som används i $2$- och $2a$-schemorna i crypt(3).

  2. Albert skriver:

    Joakim Signal kommenterade på google+ att man borde välja sha-512 istället för md5 eftersom det finns säkerhetsproblem med md5. De säkerhetsproblem som hittats gäller kollissionsattacker. Dvs att det går att hitta två klartexter som ger samma hash utan att behöva söka igenom alla kombinationer. Jag är inte säker på om kollissionsattacker kan användas för att hitta ett annat lösenord som ger samma hash. Rimligtvis borde det kunna göra det. Men det kan vara så att man måste ha lösenordet först innan man kan hitta ett till lösenord som ger samma hash med hjälp av kollissionsattacken.

    För att vara på säkra sidan bör man i alla fall undvika md5 och även sha-1 eftersom liknande kollissioner hittats även där, Sha-2 ska vara relativt säker än så länge.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s