Zabránilo by prolomení zcizených hesel použití soli?

V posledních několika týdnech došlo opět k dalšímu úniku přihlašovacích údajů uživatelů několika velkých webů, zmiňme např. LinkedIn, Last.fm, eHarmony, AndroidPhorums nebo třeba Yahoo.

V posledně jmenovaném případě byla dokonce hesla uložena v otevřeném tvaru. Obecně platí, že ve většině případů se útočník k přihlašovacím údajům dostává zpravidla prostřednictvím techniky nazvané SQL injection. Proč tak často dochází k únikům hesel a zda se této nepříjemné situaci dalo nějak zabránit, jste se mohli dozvědět např. v tomto rozhovoru: http://www.cleverandsmart.cz/proc-tak-casto-dochazi-k-unikum-hesel/.

Z nejrůznějších prohlášení odborníků na bezpečnost jednoznačně vyplývá, že kromě toho, že weby trpí zranitelnostmi, které umožňují provést SQL injection útok, tak druhou závažnou chybou je, že hesla jsou ukládána v otevřeném tvaru a pokud jsou uložena jako hashe, tak není použita sůl. Položme si však otázku, zda by za jinak stejných podmínek použitá sůl nějak výrazně hesla uživatelů ochránila.

Předpokládejme, že útočníkovi se podařilo získat DB, ve které se nachází přihlašovací údaje k určité službě a že hesla byla solená. K tomu, aby útočník mohl začít hashe hesel lámat, potřebuje ještě znát způsob, jakým je hash z hesla a soli konstruován. To útočník zjistí obvykle poměrně snadno, protože zná nejen vstup (své heslo a sůl) a výstup (hash), ale do karet mu nahrává i ta skutečnost, že na většině webů dochází obvykle k pouhému zřetězení hesla a soli. Problém by mohl nastat jedině v případě, že by heslo a sůl bylo spojováno nějakým zcela neobvyklým způsobem a útočník by se ke zdrojovému kódu nedostal.

Na tomto místě je také důležité uvést, že u naprosté většiny průniků, při kterých došlo k získání DB hesel, se útočník ke zdrojovému kódu nedostal. Nabízí se tak otázka, zda by se v případě použití nějaké bezpečné hashovací funkce, do které by vstupoval jako parametr řetězec vzniklý z hesla zadaného uživatelem a soli nějakým obskurním způsobem, nejednalo o případ, kdy by security through obscurity přístup slavil svůj úspěch, neboť postup útočníka by byl značně zpomalen.

Ovšem vzhledem k tomu, že většina vývojářů generuje hash obvyklým způsobem, budeme předpokládat, že tato situace v praxi příliš často nenastane. Útočník bude nejspíš postupovat tak, že si nejprve založí v aplikaci účet, aby zjistil, jaké jsou požadavky na heslo a poté se pokusí získat DB hesel. Pokud jsou hesla v DB ukládána jako hashe, a pro každého uživatele je použita jiná sůl, nebude moci použít rainbow tables, a bude muset hesla lámat hrubou silou.

Je zřejmé, že pokud velké množství uživatelů používá stejné slabé heslo, tak první, co útočník udělá, že bude zkoušet generovat HASH(nejpoužívanější heslo+sůl). Je celkem jedno, jak dlouhá ona sůl bude, protože vzhledem k tomu, že útočník její hodnotu zná, tak je rychlost lámání osolených hesel v podstatě závislá jen na délce a komplexitě hesla.

Jestliže daný web požaduje po uživateli heslo o minimální délce 6 znaků, bude rychlost lámání hesel ať už solených nebo nesolených v podstatě stejná. Sůl zde splní jediný účel, zabraní útočníkovi použít již vytvořené rainbow tables pro hesla o délce 6 znaků nebo použití hashů z jiného webu, kde už k jejich prolomení došlo. V okamžiku, kdy bude použito komplexní heslo o minimální délce 8 znaků, má útočník bez ohledu na solení mizivou šanci, že se mu heslo podaří prolomit.

Ovšem vzhledem k tomu, že v posledních letech se na internetu objevilo několik velice rozsáhlých databází nejpoužívanějších hesel, je mnohem pravděpodobnější, že útočník bude generovat hashe na základě této databáze. Pokud použije takový nástroj jako je např. John The Ripper, který je umožňuje provést různé modifikace daného slova na základě určitých pravidel, které např. odebírají samohlásky, přidávají číslice nebo písmena na určité pozice, nahrazují určité znaky za jiné, vypisují slovo pozpátku, je téměř jisté, že se mu tímto způsobem podaří v reálném čase prolomit velké množství hashů.

A to není všechno, pokud hesla získaná tímto způsobem přidá do slovníku a aplikuje na ně stejná pravidla, získá další hesla. Pokud se mu tímto způsobem podaří prolomit řekněme 80% hesel, která se nachází v DB, může hovořit o skvělém výsledku. Že se mu nepodařilo prolomit všechna hesla, není vůbec podstatné. Podstatná je ta rychlost a efektivita s jakou bylo možné hesla většiny uživatelů zjistit. V anglosaské literatuře se říká, že útočník cílil na low hanging fruit. Jinými slovy, proč by měl ztrácet čas lámáním všech hesel, když jich většinu prolomí tímto jednoduchým a časově nenáročným způsobem.