Tím, že máte uloženo
challenge
md5(hash_hmac(‚md5‘, $challenge, md5($password)))
už nemůžete ten challenge změnit. Pokud pošlete uživateli jiný challenge, nemůžete ověřit jeho heslo, protože máte uložen jen md5(hash_hmac(...)) s tím původním challenge.
Pokud se někdo dozví hodnotu vašeho
md5(hash_hmac(‚md5‘, $challenge, md5($password)))
je to jako by se dozvěděl heslo v plaintextu. Ví co má poslat až dostane ten jedinný challenge, který máte u příslušného uživatele uložený.
Ale neprozradí to jeho heslo, které uživatel možná používa i do jiných služeb. To je pravda.
Což je to jediné, o co v situaci popisované v článku doopravdy jde.
Ne, není to to jediné, protože:
a tím, že by se přihlásil jménem uživatele, už nic dalšího nezíská.
Může. Databázi hashů může stánout jinde, než ze systémů provozovatele (například zapomenuté zálohy na cizích serverech apod.), v databázi mohou být nějaká data zašifrovaná a k jejich rozšifrování je potřeba právě to heslo, případně se data po přihlášení získávají odjinud, z jiných systémů, ke kterým útočník přístup neměl.
Pokud by měl přímo přístup na servery a mohl změnit nebo spouštět kód, tak je to samozřejmě jiná, ale to naštěstí není tak častý případ, jako získání databáze např. pomocí "read only" SQL Injection.
Ale neprozradí to jeho heslo, které uživatel možná používa i do jiných služeb. To je pravda.
Což je to jediné, o co v situaci popisované v článku doopravdy jde. Pokud útočník dokáže získat ze systémů provozovatele webu hash hesla, často získá i další data nebo má přímo přístup do systému, a tím, že by se přihlásil jménem uživatele, už nic dalšího nezíská.
Proto tam byla ta slovíčka „doopravdy“ a „často“, která naznačují, že to není absolutní. Ale je potřeba vědět, jaké je pořadí. Nejdůležitější je, aby se provozovatel nedozvěděl přístupové údaje k jinému webu. Protože koneckonců ty údaje nemusí zneužít jenom útočník, který daný web napadne, ale může je zneužít i samotný provozovatel. Další v pořadí je, aby od provozovatele neunikala data. Protože se může stát, že uniknou jenom hesla a nic jiného, ale spíš se stane, že uniknou i další údaje. A upřímně řečeno, mně na takových únicích ze všeho nejmíň vadí právě to heslo, protože náhodných hesel vygeneruju útočníkovi kolik chce, ať si je užije, ale e-mail, adresa, objednávky, e-maily nebo co daný systém zrovna eviduje, to nechci vytrubovat do celého světa. Dále je v pořadí to, aby se na bezpečnostní problém přišlo, když už k němu dojde. A i v takové situaci se pořád útočníkovi jednoduše znemožní přístup tím, že se hesla resetují. A teprve na konci celého tohle seznamu je taková třešnička na dortu – když útočník získá přístupové údaje pro jeden server, nepodaří se mu získat jiná zajímavá data, a na útok se nepřijde, tak aby se útočník nedokázal přihlásit na web jménem uživatele. Což by zase měly odhalit bezpečnostní mechanismy, protože se přihlásí odjinud, z jiného prohlížeče atd. No a vzhledem k tomu, že by se ten standard stejně teprve musel vytvořit, nemusí se stavět na HTTP Digest, ale třeba na SCRAM, který by měl být odolnější i v případě, kdy útočník získá údaje uložené na serveru.