Salt (kryptografi) – Wikipedia

Ett salt är ett slumpmässigt tillägg till ett lösenord som gör det svårare för en lösenordstjuv att lista ut det riktiga lösenordet. Ett vanligt exempel är när man registrerar sig på ett internetforum och tilldelas ett salt som ligger dolt i ens profil. När man väljer lösenord så använder forumet en hashfunktion för att beräkna en kontrollsumma av lösenordet. Saltet adderas och forumet beräknar en kontrollsumma som sparas i databasen. När man sedan loggar in genomför forumet samma beräkning av lösenordet man skrivit in och kontrollerar om det stämmer överens med det som finns lagrat i databasen.

Eftersom lösenorden inte uttryckligen finns i databasen, utan bara bildar kontrollsummor, blir de obrukbara och värdelösa vid eventuell stöld.

För bästa säkerhet ska saltets värde vara hemligt och åtskilt från lösenordsdatabasen. Detta ger en fördel när en databas blir stulen, men saltet inte blir det. För att beräkna ett lösenord från en stulen hash (initieringsvektor), kan en angripare inte bara försöka lösa koden med hjälp av några gemensamma lösenord (till exempel ord eller namn). Snarare måste de beräkna varje hash av slumpmässiga tecken (åtminstone för de delar som de vet är saltet), vilket är mycket långsammare.

I vissa kommunikationsprotokoll, är saltet överfört som klartext med krypterade data, ibland tillsammans i flera upprepningar som används för att generera krypteringsnyckeln. Kryptografiska protokoll som använder salter inkluderar SSL och Ciphersaber.

Ett tidigt UNIX-system med ett 12-bitars salt, med moderna tillämpningar använder större värden.

Salt är nära förknippad med begreppet nonce (udda nummer som används endast vid ett tillfälle) och cnonce (klientspecifikt engångsnummer).

Fördelen som blir med hjälp av ett saltat lösenord är att en enkel databiblioteksattack mot "krypterade värden" blir opraktiska om saltet är tillräckligt stort. En angripare skulle inte kunna använda en regnbågstabell, en ordlista med krypterade värden (lösenord + salt), eftersom det antingen skulle ta alltför lång tid eller uppta alldeles för mycket utrymme. Detta skulle tvinga angriparen att använda den angivna autentiseringsmekanism (som "vet" det korrekta saltvärdet).

Antag att en användares (krypterade) hemliga nyckel blir stulen och användaren är känd för att använda ett av de 200 000 vanligaste orden i sitt lösenord. Systemet använder ett 32-bitars salt. Det viktiga är nu det ursprungliga saltade lösenordet som bifogats med detta slumpmässiga 32-bitars salt. På grund av detta salt, är angriparens förkalkylerade hashar helt värdelösa. Man måste beräkna ett hash för varje ord med vardera 2³² (det vill säga 4 294 967 296) möjliga bifogade salter tills en matchning kan hittas. Det totala antalet möjliga faktorer som då kan erhållas genom att multiplicera antalet ord i ordlistan med antalet möjliga salter blir:
${\displaystyle 2^{32}\times 200000=8.58993459\times 10^{14}}$

För att slutföra en brute force-attack, måste angriparen nu beräkna cirka 800 biljoner olika hash, istället för endast 200 000. Även om lösenorden själva är kända för att vara enkla, gör det hemliga saltet att lösenordsknäckandet blir allt svårare.

Tidigare versioner av UNIX använde en passwd-fil för att lagra hashsaltade lösenord (lösenord förvanskade med två teckens slumpmässiga salter). Observera att i dessa äldre versioner av Unix är salt också lagrat i passwd (i klartext) tillsammans med hash av saltade lösenord. passwd-filen är allmänt läsbar för alla användare av systemet. Det måste vara läsbart så användarvänliga privilegierade mjukvaruverktyg kan hitta användarnamn och annan information. Säkerheten kring lösenord skyddades endast av skymmande funktioner (krypteringsutrustning eller hashning) som användes för ändamålet.

I tidiga Unix-tillämpningar begränsades lösenorden till 8 tecken och använde ett 12-bitars salt, vilket möjliggjorde för 4.096 olika möjliga saltvärden. Medan 12 bitar var bra nog för de flesta ändamål under 1970-talet (även om några tvivlade redan då), hade år 2005 disklagring blir billigt nog så att en angripare kunde räkna ut alla dessa olika salt för miljontals av de vanligaste lösenorden, inklusive alla 4.096 möjliga saltvarianter för varje lösenord och lagra dessa i förhand beräknade värden på en bärbar hårddisk. En angripare med en större budget kunde bygga en hårddiskgrupp med alla 6 karakteristiska lösenord och de vanligaste 7- och 8-teckens lösenord lagrade i krypterad form, för alla 4 096 möjliga salter.

I moderna shadow password-system, i vilket lösenordshash och annan säkerhetsrelaterad information lagras i en icke-offentligt fil, minskar något dessa problem. Men de är fortfarande aktuella i multi-server installationer som använder ett centraliserat lösenordsledningssystem som "push"-lösenord eller lösenordshash till flera system. I sådana anläggningar skall root-kontot på varje enskilt system behandlas som mindre "pålitliga" än vid administration av de centraliserade lösenordssystemen, så det är värt att se till att säkerheten för lösenords-hashing-algoritmer, med framtagning av unika "salt "värden, är tillräckliga.

Salter skyddar också mot de regnbågstabeller som i själva verket förlänger potentiellt komplicerade lösenord. Om regnbågstabellerna inte matchar lösenordslängden (t.ex. ett 8-bitars lösenord och 2-bytes salt, är det i praktiken ett 10-bytes-lösenord) och komplexiteten (icke-alfanumeriska salt ökar komplexiteten i ett strikt alfanumeriskt lösenord) med saltade lösenord, så det inte kan hittas. Om det hittas kommer det vara nödvändigt att ta bort saltet ur lösenordet innan det kan användas.

Ett salt gör också databiblioteksattacker och brute force-attacker för kodknäckare med stort antal lösenord mycket långsammare (men inte i fråga om att dechiffrera bara ett lösenord). Utan salter, kan en angripare som försöker knäcka många lösenord vid en och samma tidpunkt, endast komma att behöva gissa en hash för varje lösenord bara en gång för att sedan jämföra den med alla hashes. Men med salter, kommer varje lösenord ha unika salter, så att varje gissning måste dechiffrera varje hash separat, för varje salt, vilket blir mycket långsammare eftersom hashing är oftast mycket beräkningsmässigt kostsamt.

En annan fördel med en salt är följande: två användare kan välja samma sträng som sitt lösenord, eller att samma användare kan välja att använda samma lösenord på två maskiner. Utan salt skulle detta lösenord lagras som samma hash strängen i lösenords-filen. Detta skulle avslöja det faktum att de två kontona har samma lösenord, så att alla som känner ett av kontots lösenord kan komma åt det andra kontot. Saltning av lösenordshash med två slumpmässiga tecken, gör att - även om de båda kontona använder samma lösenord - kan ingen kan upptäcka detta genom att läsa passwd-filer.

Den här artikeln är helt eller delvis baserad på material från engelskspråkiga Wikipedia, tidigare version.

• Morris, Robert; Thompson, Ken (1978-04-03), Password Security: A Case History, Murray Hill, NJ, USA: Bell Laboratories, arkiverad från ursprungsadressen den 2003-03-22, https://web.archive.org/web/20030322053727/http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps 
• Wille, Christoph (5 januari 2004). ”Storing Passwords - done right!”. Bernhard Spuida(översättning). http://www.aspheute.com/english/20040105.asp. 
• Primer on Unix password structure