F15 Hashning och datasäkerhet
Lösenord
Lösenord bör sparas saltade och hashade. Att salta ett lösenord gör man genom att lägga till varje lösenord lägga till en hårdkodad sträng innan man hashar.
Exempelvis skulle en hårdkodad lösenordsfunktion:
def testaHemligtPassword( password ):
if password == "123aabbccdd" :
return True
else:
return False
kunna skrivas så här:
def dunkeltPasswordsTest(password):
hårdkodat_salt = "123£"!#¤!..."
hårdkodat_saltat_och_hashat_lösen = "312sd3$£$#!SESD..."
hashat_password = hashfunc( password + hårdkodat_salt)
if hashat_password == hårdkodat_saltat_och_hashat_lösen :
return True
else:
return False
Givet koden är det svårt att gissa lösenordet. Eftersom en hashfunktion kan ge samma värde för två helt olika indata (krock) så går det inte att, givet hashvärdet, lista ut vilket det ursprungliga värdet var.
Lösenorden i algoritmen är inte hårdkodade som i koden ovan utan lagras på disk. Det är mycket vanskligt att lagra lösenord i klartext, det finns flera pinsamma exempel där lösenordsdatabaser läckt från stora företag. Det är tyvärr vanligt att användare återanvänder lösenord och de kan drabbas av att illvilliga personer som provar logga in med läckta lösenord på andra ställen. Lösenord bör lagras saltade och hashade på disk eller i databas. Man kan ha två salt, ett hårdkodat i programmet och ett slumpat som lagras tillsammans med lösenordet i databasen. Det slumpade saltet gör att samma lösenord ger helt olika hashningar att lagra.
| användarnamn | lösenord | salt | att hasha | att lagra |
| klas | qwerty | EE£@ | qwertyEE£@ | ASD#"¤#"31we1sadsd322 |
| anna | qwerty | RTT! | qwertyRTT! | GRwesakoRWSDasdlm34 |
Lösenordsalgoritm med utmaning (challenge)
Antag att en användare vill logga in på en server via en okrypterad förbindelse. Om någon tjuvlyssnar på förbindelsen så kan denne komma åt lösenordet om man naivt skickar login och password över nätverket.
Istället skickar servern skickar data till den som loggar in och låta användaren koda/hasha datat, servern gör samma sak och jämför med användaren. Algoritmen blir ungefär så här
- Klienten tar kontakt med servern och skickar sitt username och ett slumpat klientmeddelande
- Server slår upp usern i databasen och hämtar det sparade saltade och hashade lösenordet
- Servern slumpar en siffra, ett iterationsantal
- Servern slumpar ett utmaningsmeddelande (challenge)
- Servern skickar till klienten:
- iterationsantal
- utmaningsmeddelande och
- klientmeddelandet
- lagrat slumpat salt i databasen
- Klienten använder sitt lösenord tillsammans med saltet för att hasha utmaningsmeddelande+klientmeddelande flera (iterationsantal) gånger och skickar resultatet till servern
- Servern för samma sak och jämför med klientens resultat
I förenklad konversationsform:
Klient: Tjena det är klas hasha det här "AWeQ"
Server: Använd detta salt "EE£@"och hasha "AWeQ+iiiLLK!" 4 gånger
Klient: OK, jag fick "asdkoEE!#Sdllee!"
Server: OK, det fick jag med, jag låter dig logga in
Att välja lösenord
Det finns bra och dåliga lösenord (Länkar till en externa sida.). I mars 2013 anordnade nättidningen Ars Technica en tävling att gissa hashade lösenord. Artikeln beskriver hur lösenordsgissningsalgoritmerna jobbar (Länkar till en externa sida.). Bl.a. används befintliga lösenord som algoritmen hakar på suffix och prefix. Bruce Schneier är en säkerhetsexpert som bloggar om datasäkerhet och ger en del råd om lösenord (Länkar till en externa sida.).
Validera indata
Ett användarvänligt program berättar för användaren om indata är på fel format så att hen har chans att rätta till det. Men det finns ytterligare skäl till att validera inmatning innan den skickas vidare till programmet - det är en möjlig säkerhetsrisk.
Kontrollera t ex:
- Indatas längd
- Datatyp
- Filformat (inte bara ändelsen)
Dekompilera kod
Under 2014 publicerades två artiklar (1 (Länkar till en externa sida.), 2 (Länkar till en externa sida.)) som kunde visa att det går att skriva kod som inte går att hacka (Länkar till en externa sida.). Definitionen på ej hackningsbar skulle vara att den som har tillgång till källkoden inte vet mer än den som har den kompilerade koden. För den senare fungerar koden som en svart låda (black box).
Mer att läsa
I Simon Singhs kodbok (Länkar till en externa sida.) finns tio chiffreringsuppgifter av stigande svårighetsgrad. De första att knäcka alla tio var ett lag med dåvarande/blivande doktorander i teorigruppen TCS på CSC, Här är deras berättelse (Länkar till en externa sida.) om hur det gick till.
En fortsättningskurs som bland annat handlar om tillämpningar av kryptering är DD2395 Datasäkerhet (Länkar till en externa sida.). Där får man också lära sig om t ex virus och datajuridik.
Säkerhetsaspekter tas även upp i kursen DD1334 Databasteknik (Länkar till en externa sida.) som vissa av er läser redan i vår.
Vi har förstås också kursen DD2448 Kryptografins grunder (Länkar till en externa sida.) (men den kräver att man läst DD1352 ADK (Länkar till en externa sida.) först).