Dotaz: Význam, použití, bezpečnost saltů u hashů

[vasek]

Tak jsem začal pročítat různá fóra a články a mám pocit že teď vím o solení hesel ještě míň než před tím. Někdo tvrdí, že se dá salt z hesla oddělit a pak je vlastně zbytečný, někde se píše že je to blbost, někde že musí být salt utajen, jinde že salt může být klidně veřejný ... Jak to tedy je? Prosím vysvětlete mi to od píky nebo mě odkažte na nějaký článek, ve kterém píšou pravdu . Je mi jasný, že si heslo mohu osolit "po svěm" tím, že za něj prostě připojím nějaký řetězec, který bude znát jen daná aplikace: heslo+retezec. Nerozumím ale moc principům těch funkcí, které solí hesla, co s tím vlastně udělají apod. Např. moc nechápu co přesně provede s heslem třeba funkce v PHPčku crypt('heslo', '$6$sul$'). Jasně, vytvoří to sha512 osolený druhým parametrem, ale co se rozumí tím solením - přidání řetězce na začátek hesla nebo zašifrování hesla tím saltem... ?

Odpovědi

[Ash]

Výhoda solení je, pokud máte hesel víc. Stejná hesla pak díky soli mají různý hash, takže nemá význam třídit hashe a hádat podle četnosti které heslo asi je nbusr123.

[pht]

To se má tak. Proč se hesla hashují? Aby z jejich uložené podoby (v souboru, v databázi, ...) nebylo to heslo hned zřejmé. Když někdo znásilní takovou databázi, aby neměl hned hesla všech uživatelů (které můžou používat i k jiným účelům).

Jenže. Hashovací funkce je udělaná tak, aby na stejný vstup dávala stejný výstup (proto máme sha součty u stažených souborů atd.) Takže když někdo bude vědět že hashem hesla "franta" je hodnota 1234, tak mu stačí najít 1234 v databázi a bude vědět, že daný uživatel má heslo "franta". Tomuhle útoku kde máme předpočítanou tabulku hashů se říká rainbow tables attack.

A tady do hry vstupuje ta sůl. To je prostě několik náhodně vygenerovaných znaků navíc - např. "asdf". Hashuje se pak řetězec který vznikne spojením hesla a soli, tedy "asdffrata". Dejme tomu, že ten hash je 4567. V databázi pak máme hash a sůl, tedy "asdf|4567". Znamená to "zeptej se uživatele na heslo a k tomu co ti řekl přilep asdf, zahashuj, a pokud ti vyjde 4567 tak je zadané heslo správné".

S tímto přístupem už nelze mít předpočítanou tabulku hashů, protože sůl může být u každého hesla "franta" jiná a tudíž i hash bude jiný. Velikost soli se obvykle volí tak, aby nebylo praktické mít předpočítané všechny soli. Jedinou možností je teď útok hrubou silou, kde zkoušíme k soli z databáze přilepit různá hesla, hashujeme a díváme se, jestli nevyšel ten správný hash. To je ale výpočetně nesrovnatelně více náročné než ta rainbow tabulka.

V tomto schematu není sůl o nic víc tajná než její náležící heslo-hash. Jinak určitě může existovat ještě 150 dalších krypto schemat, kde má sůl úplně jinou roli.

[koso]

Mozeme pouzit jednoduchy priklad:

Predstavte si, ze ste utocnik a nejakym sposobom sa vam podarilo ziskat hash hesla konkretneho uzivatela z DB a nech je to hash1 = ab24a...............34cd.

Kedze absolutna vacsina uzivatelov su laici a volia hesla tak aby si ich pamatali, a nie tak aby boli bezpecne -> skusite pri hladani hesla vyuzit slovnik, resp. databazu najpouzivanejsich hesiel. Ku kazdemu heslu zo zoznamu vypocitate hash (alebo najdeme uz predpocitane na internete), a porovnate ho s hash1. Pripadne mozete generovat vsetky hesla do urcitej dlzky pozostavajuce z pismen a cislic, ale to uz je komplikovanejsie. Ak mate dostatok stastia, tak hladane heslo bolo zmysluplne a bolo v slovniku = vyhrali ste.

Teraz si ale predstavte, ze je pouzita sol. Ta svojim sposobom modifikuje zadane heslo pred vypoctom hashu. Zvolme sol tak, ze osolene heslo uz nebude pozostavat len z abecedy a cislic. Je silne nepravdepodobne, ze by takto modifikovane heslo bolo zmysluplne, alebo ze by sa nachadzalo v nejakom slovniku najpravdepodobnejsich hesiel, a tak sa utok vyrazne komplikuje. Ak by sme aj chceli generovat vsetky mozne hesla, mame 2 zasadne problemy ... nevieme dlzku (nestaci odpozorovat pocet stlacenych klaves) a kazdy bajt hesla moze mat 256 moznych hodnot .. co je vyrazne viac, ako keby heslo pozostavalo len z pismen a cislic. Ak je sol, resp. postup modifikacie hesla pred hashovanim, kvalitne navrhnuty, tak pri utoku sa stracaju vsetky vyhody predosleho pripadu a utok zacina byt ekvivalentny s hladanim "first preimage".

[koso]

Este dodatok k druhemu pripadu:

Ak sa vam aj nejakou nahodou podari najst retazec, ktory dava hash1, ziskate tak len heslo PO osoleni. Za predpokladu, ze sol zostava utajena a nie je trivialna, by bolo viacmenej nerealne ziskat povodne heslo.

[fraxinus]

MD5 hash slova "secret" je "dd02c7c2232759874e1c205587017bed". Ak utocnik ziska md5 nesolene hashe tak staci polozit dotaz do googlu a hned vie ze heslo je "secret". Velke mnozstvo beznych vyrazov sa takto da cez google najst bez nutnosti pouzit brute force. Ak pouzijes salt tak aj ked sa utocnik dozvie ten salt tak cez google dane hashe nenajde lebo nikdo nebude davat na web md5 sucty osolene vsetkymi moznymi solami. Proste solenie mierne zvysuje bezpecnost.

[vasek]

Zde je příklad z php.net k fci crypt:

crypt('rasmuslerdorf', '$1$rasmusle$') = $1$rasmusle$rISCgZzpwk3UhDidwXvin0

Řetězec za "$1$rasmusle$" je zaheslované heslo s pomocí saltu. rasmusle je v hesle jako celý plaintext proč? Třeba u SHA-512 je tam jen kus toho plaintextu viz. http://php.net/manual/en/function.crypt.php.

[fraxinus]

lebo crypt je blba funkcia. Ja solim takto:

  $password = 'secret';
  $salt = 'jablko';
  $s = sha1($password.$salt);   
  echo $s;                      // vypise 176b05b6e83a3669639eef184f33d651d48e3eb4

[dzim]

Cimz v podstate vytvarite novou (obskurovanou) hashovasci funkci na misto saltovani.

[koso]

U SHA-512 je to orezane, pretoze podla specifikacie funkcie crypt (ten isty link) je ako salt pozadovany vstup 16 znakov ... tie zvysne su pravpodobne ignorovane pri samotnom vypocte, ale to si mozete velmi jednoducho vyskusat.

[pht]

rasmusle je v hesle jako celý plaintext proč?

Sůl musí být dodána plain jinak byste při kontrole hesla nevěděl co k heslu přidat.