Ano, porovnání řetězců (a/nebo vyhledávání indexů) může v zásadě prozradit, kolik identických úvodních bajtů hash hesla je uložen v databázi a kolik je vypočteno ze zadaného sdílení hesla.
V zásadě by toho mohl útočník použít k tomu, aby se iterativně naučil předponu hash hesla, bajt po byte:nejprve najde hash, který sdílí svůj první bajt s hashem v databázi, pak ten, který sdílí jeho první dva bajtů a tak dále.
Ne, na tom téměř jistě nezáleží.
Proč? No, z několika důvodů:
-
Útok načasování může umožnit útočníkovi zjistit část hash hesla uživatele. Dobře navržené schéma hashování hesel (pomocí soli a roztažení klíče ), by však měla zůstat bezpečná (samozřejmě za předpokladu, že samotná hesla nelze snadno uhodnout), i když útočník zná celé hash hesla. Tedy i když bude útok načasování úspěšný, samotná hesla budou v bezpečí.
-
K provedení útoku musí útočník zadat hesla, jejichž hash hodnotu zná. Hodnota hash závisí na soli. Pokud tedy útočník již sůl nějak nezná, není tento útok možný.
(Je pravda, že ve většině bezpečnostních analýz schémat hašování hesel je sůl považována za veřejnou informaci. Je to však pouze proto, že takové analýzy předpokládají nejhorší možný scénář uvedený výše, kdy útočník již získal kopii celou uživatelskou databázi, soli a hash a tak dále. Pokud útočník ještě nezná hash, není důvod předpokládat, že by sůl znal.)
-
I když útočník zná sůl, aby mohl provést iterativní útok popsaný výše, bude muset vygenerovat hesla, která hashují na hodnotu s požadovanou předponou. U jakékoli zabezpečené hašovací funkce je jediným praktickým způsobem, jak toho dosáhnout, metodou pokus-omyl, což znamená, že čas potřebný k tomu se exponenciálně mění s délkou předpony.
V praxi to znamená, že za účelem extrahování dostatečného množství bitů z hashe, aby bylo možné proti němu provést offline útok hrubou silou (což nemusí být všechny; jen více než efektivní množství entropie v heslo), útočník potřebuje provést přibližně tolik výpočtů, kolik je potřeba k prolomení samotného hesla. Pro dobře navržené schéma hashování hesel a bezpečně zvolené heslo to není možné.
-
Co iterativní útok může dát útočníkovi je v zásadě schopnost provádět většinu výpočtů hrubou silou lokálně na jejich konci, přičemž do vašeho systému odesílá pouze poměrně malý počet hesel. I to však platí pouze v případě, že od každého obdrží zpět podrobné a spolehlivé informace o načasování heslo odesláno. V praxi jsou útoky s reálným načasováním extrémně neefektivní a vyžadují mnoho (často tisíce nebo miliony) dotazů, aby získali jakýkoli vůbec užitečné informace. To velmi pravděpodobně zruší všechny potenciální výhody výkonu, které by mohl útočníkovi poskytnout načasovaný útok.
Tento bod je umocněn tím, že používáte správné schéma hašování hesla pro roztahování klíčů, protože taková schémata jsou záměrně navržena tak, aby byla pomalá. Porovnání řetězců v databázi tedy pravděpodobně zabere zanedbatelnou dobu ve srovnání s hašováním hesla na prvním místě a jakékoli změny časování způsobené tím budou ztraceny v šumu.