Salt - ett substitut för dåliga lösenord?

[Robert Malmgren]

Magnus Lindkvist wrote:
>
> Jag och kollega gick en promenad idag och funderade lite på det här
> med salt och hur *nix system funger. Efter mycket diskussion fram och
> tillbaka så kom vi fram till att salt är bara ett substitut för dåliga
> lösenord. Eftersom varken jag eller kollegan visste hur *nix hanterar
> salt så resonerade vi oss till följande teori. (man skulle också kunna
> söka fram denna info på nätet ist för att spamma ner en lista – men
> det är inte lika kul)
>
>  
>
> Ponera att vi bara använder siffror och inte bokstäver. Ponera också
> att varje användarnamn är endast en siffra. Ponera att vi använder två
> siffror salt. Exempel:
>
>  
>
> Login: 1
>
> Salt: 2,3
>
> Totalt: 123
>
>  
>
> Jag antar att 123 nu körs genom godtycklig hashalgoritm och vips har
> vi ett hashat lösenord. Med denna teknik så skulle det alltså finnas
> 10 olika sorters login och 100 olika sorters salt. Kombinerat så
> skulle det bli max 1000 kombinationer. En rainbowdatabas med 1000
> hashar skulle mao kunna knäcka alla tänkbara kombinationer.
>
>  
>
> Så nu kommer mina två frågor/påståenden:
>
> 1, Varför använda salt? Är det inte bättre att lära folk att ha säkra
> (längre och komplexa) lösenord? Tvingar du användaren att ha ett tre
> tecken långt lösen utan saltfunktion så blir det exakt samma resultat
> – eller?
>

Bortsett från vad alla andra skrivit om detta i tråden, så bör man börja
med att sätta saker och ting i rätt sammanhang, inte minst tids- (och
därmed CPU- och lagringsvolyms-) mässigt.

När Robert Morris Senior (vars son gjorde Internetmasken) gjorde om
lösenordshanteringsfunktionen[1] i en tidig version av UNIX så
utvecklade han en speciell falluckefunktion baserad på en permutation av
DES som tog 1 sekund[2] på dåtidens balla hårdvara som de hade tillgång
till på Bell Labs - en PDP-11/70.

Detta var, som kanske det behövs påminnas om, tiden långt innan
rainbowtables. För att försvåra för någon att komma på idén att göra
just en fet databas med förberäknade hashar som skulle fungera på valfri
dator som man snodde /etc/passwd från, så infördes konceptet med "salt"
för att permutera så att samma lösenord på data X inte skulle sparas med
samma hashresultat på dator Y. Med ett 12-bitars saltvärde så fick man
4096 permutationer på en hash för samma klartextvariant av lösenordet.

Så idén var nog snarast att få det omöjligt med dåvarande hårdvara
(RK05or, TK-taper och CPUer som inte gjorde GHz-fart) att skapa det, som
man nu 30 år senare, kan göra med 250Gb diskar och rainbowtables.

Så salt har ju inget att göra med själva kvaliteten på
klartextlösenordet i sig självt att göra, utan snarare skall ses som
formatet i vilket de permuterade hasharna hanteras för att undvika att
samma indataklartext alltid genererar samma utdatahashvärde.

[1] http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
[2] http://members.value.com.au/christie/usenix91.htm


--r
>
> 2, Används salt i Kerberos?
>
>  
>
> Magnus
>
>  
>
> PS
> Jag ringde både Tom, Haba och Levitte för att få lite mer info runt
> detta och tackar för deras assistans i tankeprocessen.
>
> DS
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Stacken mailing list, Stacken at stacken.kth.se
> https://lists.stacken.kth.se/mailman/listinfo/stacken
>