Salted hash – další krok ke zvýšení bezpečnosti

10. února 2005

•

Na Intervalu jsem se nejen já již věnoval šifrování, hešování i teorii úschovy hesel pro přístup k webovému sídlu. Tentokrát bych rád demonstroval další bezpečnostní techniku pro uchovávání hesel – salted hashes. Použití této techniky představuje další krok ke zvýšení bezpečnosti vašeho webu. Článek jsem navíc pojal jako sumarizaci a srovnání již probraných bezpečnostních postupů.

Pokud na svém sídle uchováváte nějaká hesla, máte v zásadě čtyři možnosti, jakým způsobem tato hesla „chránit“. Slovo chránit je v uvozovkách záměrně, protože například hned první možnost není žádnou ochranou!

Možnost první – plain-text

Tak na tuto možnost zapomeňte. Tato technika spočívá v tom, že hesla uchováváte v prosté textové podobě. Prostě je nijak nešifrujete. I když by se mohlo zdát, že váš web neobsahuje žádná citlivá data, není tomu tak. Vzhledem k faktu, že většina uživatelů volí vždy stejná hesla pro přístup do různých sídel (e-mail, e-banking a další) je heslo samo o sobě to nejcennější!

Možnost druhá – šifrované heslo

Tento způsob skrytí textu před nepovolanými zraky jsem popsal ve článku Cryptography v .NET. V textu Uchovávejte správně hesla! jsem však také poznamenal, že tento způsob není vhodný pro oblast hesel. Už jen z toho důvodu, že není nikdy opodstatněný důvod heslo dešifrovat do původní podoby. Tento způsob zabezpečení je určen spíše pro tajné zprávy, které je někdy někde nutno rekonstruovat.

Možnost třetí – hešované heslo

Teď už jsme se alespoň dostali do rozumné sféry ochrany hesel. Hešování hesel by mělo být samozřejmostí. Rekonstruovat původní podobu z heše není triviální záležitostí. Ono se vlastně ani o žádné rekonstrukci mluvit nedá. Zjišťování může probíhat spíše tak, že se porovnávají hešové reprezentace slov ze slovníku s hešem, který si hacker vytáhl z vašeho webu. Dříve nebo později budou heše shodné a jelikož moderní hešovací algoritmy jsou vcelku dobře vybaveny proti kolizím hešových hodnot (těžko tedy najdete dva různé řetězce, které budou reprezentovány stejnou hešovou hodnotou), má útočník velkou naději, že jeho vstup je shodný s heslem uživatele.

Aby byl tento typ útoku na váš web co nejtěžší, měli byste uživatele nějak přinutit, aby používali hesla delší, aby při tvorbě použili některé „nestandardní“ znaky, kombinovali velká a malá písmena a podobně. To je samozřejmě úkol nadlidský. Z důvodu snadné zapamatovatelnosti si hodně uživatelů volí jako heslo nějaké jednoduché slovo, často pak ještě snadno odhadnutelné (jméno partnera patří mezi nejstrašnější a nejpoužívanější). Vývojářům se však nabízí další možnost – přidat k heslu náhodnou posloupnost znaků – salt.

Možnost čtvrtá – salted hash

Tato možnost není zas až tolik odlišná od předchozí, je však trochu odolnější proti brute-force útokům. Spočívá v tom, že k heslu připojíte náhodnou posloupnost znaků, takzvaný salt. Vzniklý řetězec pak teprve hešujete. Útočník tak nemůže použít již předem hešovaný slovník, ale musí slova ze svého slovníku spojit se saltem a teprve potom hešovat. Tento postup ho alespoň o něco zpomalí, nikoli však zastaví. Spíše, řekl bych, odradí.

Autoři vesměs zastávají postoj, že salt jako takový není nic tajného a může se klidně uložit do databáze jako další pole. Tajné je však to, jak je salt použit (jestli je připojen na začátek, na konec, za druhý znak a podobně). Databáze uživatelů pak může vypadat zhruba takto:

Jako další krůček to zcela jistě postačuje. Salt můžete také uložit do úplně jiného souboru. Ověření hesla pak ale zabere o něco více času. Je jen a jen na vás, jaký způsob zvolíte.

Teď se podívejte na hesla v databázi předchozího příkladu. Těžko můžete odhadnout, jestli mají někteří uživatelé stejné heslo. Kdybychom nepoužili salt, databáze by vypadala takto:

Všichni uživatelé mají totiž heslo úplně stejné. Bez saltu je to jasně vidět. Kdyby hacker získal heslo Pepy, měl by rovnou hesla čtyř osob. Použijeme-li salt, musí, chce-li mít všechna hesla, zjišťovat dál analogickým způsobem – přes hešovací algoritmy. To mu opět zabere čas navíc.

Na závěr uvedu praktickou demonstraci:

public void hashtext_Click(Object sender, EventArgs e)
{
byte[] bsalt = new byte[6];
new RNGCryptoServiceProvider().GetBytes(bsalt);
string salt = Convert.ToBase64String(bsalt);
byte[] bdata = Encoding.UTF8.GetBytes(tbVstup.Text + salt);
byte[] bhash = new SHA256Managed().ComputeHash(bdata);
string hash = Convert.ToBase64String(bhash);
// tak a mame salted hash…
tbSalt.Text = salt;
tbHash.Text = hash;
}

Ověření platnosti uživatelského vstupu je jen analogie demonstrovaného postupu. Vstup by se spojil se saltem v databázi, nechal proběhnout hešovacím algoritmem a výsledek by se porovnal s hodnotou uloženou v databázi. V ukázce máme salt a hash v textové podobě, stačí je jen uložit do databáze.

U některých autorů jsem se setkal i s jiným způsobem „saltování“ heše – před hešováním je možné místo „klasického“ saltu připojit k heslu jméno uživatele. Pokud zadáte jako podmínku pro volbu uživatelských jmen minimální délku jména na například pět znaků, bude jméno-salt dostatečně dlouhé, aby zajistilo slušnou variabilitu. Je to, myslím, vcelku rozumně použitelné, ušetříte jedno pole v databázi a útočník na první pohled nepozná, používáte-li salt.

Jak vidíte z příkladu, použití tohoto postupu vám nedá o moc více práce než ukládat hesla v plain-textu! Nic vám navíc nebrání napsat si vlastní třídu jejíž používání vám v budoucnu další práci usnadní a urychlí, takže vás zvýšení bezpečnosti všech vašich aplikací nebude stát žádnou námahu navíc.