Hlavní navigace

Vlákno názorů k článku „Jak ukládáme hesla, vám z důvodu bezpečnosti neprozradíme“ od martin - Tím, že máte uloženo challenge md5(hash_hmac­(‚md5‘, $challenge, md5($password))) už nemůžete ten...

  • Článek je starý, nové názory již nelze přidávat.
  • 14. 10. 2016 12:38

    martin (neregistrovaný)

    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.

  • 16. 10. 2016 23:57

    ldx (neregistrovaný)

    Ale každý uživatel má unikátní vlastní challenge ne? Aspoň tak jsem to pochopil...

  • 14. 10. 2016 16:24

    ">Michal Špaček

    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.

  • 14. 10. 2016 15:45

    Filip Jirsák

    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á.

  • 14. 10. 2016 17:28

    Filip Jirsák

    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.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).