Hlavní navigace

“Jak ukládáme hesla vám z důvodu bezpečnosti neprozradíme”

Michal Špaček

Když na otázku “jak ukládáte hesla?” dostanete neurčitou odpověď nebo když vám to někdo nechce prozradit, spíš očekávejte, že vaše hesla nejsou v bezpečí.

Zajímá vás, jak firmy jako Facebook, Dropbox, Fakturoid, WEDOS.cz a další ukládají vaše hesla? Já to vím a z důvodu bezpečnosti vám to i prozradím, tyto firmy se to totiž nebály zveřejnit. 

Začal jsem takové informace sbírat a teď bych vás na prohlídku mojí sbírky motýlů rád pozval. Vstup je zdarma, otevřeno máme celý den. Sbírku v současné chvíli asi 30 firem najdete na https://pulse.michalspacek­.cz/passwords/storages:

Když vám to někdo z “důvodu bezpečnosti” nechce prozradit, tak spíš očekávejte, že vaše hesla nejsou v bezpečí.

Hodnocení

U každého webu najdete v detailech odkaz na informaci o ukládání hesel, kterou zveřejnila samotná firma, její zaměstnanec, nebo někdo nezávislý. Způsob ukládání i zveřejnění je ohodnocen známkou A až F, kde F je nejhorší možný způsob ukládání hesel, tedy v čitelné podobě. 

Známky A i B naznačují bezpečný způsob ukládání hesel, ale liší se jen tím, kde firma informaci zveřejnila. Když se firma k bezpečnému způsobu ukládání hesel přiznává na “viditelném” místě (v dokumentaci, přímo na webu apod.), tak dostane nejlepší známku A. Když je přiznání trochu skryté (v nějaké přednášce, na blogu nebo na Twitteru), je ohodnoceno pouze známkou B. 

Hodnocení C, D a E znamená, že firma nedodržuje doporučení pro bezpečné ukládání hesel, ale aspoň se více (C ) či méně (E) úspěšně snaží něco dělat. Pro detailnější popis se podívejte na stránku s vysvětlením jednotlivých známek, odpovědi na další otázky najdete na stránce Questions?

Proč?

Tímto projektem se snažím zprůhlednit ukládání uživatelských hesel, pozitivně motivovat firmy ke zveřejňování informací a tím nepřímo zvýšit zabezpečení takových úložišť. Spousta firem uživatelská hesla ukládá nevhodně a tím kriticky ohrožuje své uživatele, kteří velmi často používají jedno heslo na více místech.

Z důvodu bezpečnosti…

Firmy by se neměly obávat zveřejnit, jak hesla ukládají, zvlášť když to dělají dobře. Pokud to dobře nedělají, pak by ukládání hesel měly předělat a pak to mohou zveřejnit. Jenže když na otázku “jak ukládáte hesla?” dostanete neurčitou odpověď (podobnou té v titulku), nebo když vám to někdo z “důvodu bezpečnosti” nechce prozradit, tak spíš očekávejte, že to nedělají dobře a že vaše hesla nejsou v bezpečí.

Ukládáme hesla, měli bychom zveřejnit jak?

Dobrá otázka :-) Ano, měli byste, dáváte tak najevo, že se snažíte data uživatelů chránit a tím zvyšujete svoji důvěryhodnost. Podle hodnotící stupnice si můžete jednoduše ověřit, jakou známku byste dostali, a pokud se vám nelíbí, tak s tím něco udělejte. V každém případě mi dejte vědět, ať vás mohu do své sbírky zařadit. Tento projekt jsem prezentoval v srpnu na konferenci BSides/Passwords v Las Vegas (a znovu koncem září na WebExpu v Praze) a od té doby se mi ozvalo několik společností s tím, abych je na seznam zařadil, například:

  • prodejce HTTPS certifikátů CertSimple
  • server pro profesionály v informační bezpečnosti Peerlyst
  • český MALL.CZ
  • již zmíněný Fakturoid
  • Shipito
  • … kdo bude tím dalším?

Slajdy a video z přednášky najdete u mě na webu (kratší a méně technické video z konference WebExpo je tady).

Pokud byste potřebovali pomoci s hashováním hesel nebo čímkoliv jiným, kontaktujte mě, rád pomohu.

Redakční dodatek 

Tento text původně vyšel na facebookovém profilu Michala Špačka. Dodáváme k němu ještě dvě informace:

START17

Vydavatelství Economia má v seznamu hodnocení F, založené na poznatku z roku 2014, že ukládá hesla v plaintextu. Šéf IT Štěpán Burda Lupě potvrdil, že to už delší dobu není pravda. „Všechny hříchy z minulosti na iHNEDu postupně řešíme a hesla v plaintextu byla první na seznamu. Takže už nějaký ten rok používáme pro ukládání hesel bcrypt (blowfish),“ napsal Lupě s tím, že nový stav platí nejméně od konce roku 2014.

A jak ukládáme hesla na serverech Internet Info? „Autentizaci řešíme metodou challenge-response. V databázi tedy máme uloženo $challenge (náhodně vygenerovaný řetězec) a dále md5(hash_hmac(‚md5‘, $challenge, md5($password))), tedy zahashované heslo smíchané s $challenge,“ říká technický ředitel Martin Calta. Změna na pomalé hashovací funkce by podle něj mohl přijít po přechodu všech webů vydavatelství na HTTPS.

Našli jste v článku chybu?
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 nep…