E-mail s heslem dokazuje vratnost, ne schéma úložiště

Služba, která posílá aktuální heslo uživatele e-mailem, dokázala jednu věc: dokáže toto tajemství získat v podobě, kterou umí odeslat. Nedokázala však, který sloupec, algoritmus nebo knihovna ho vytvořily. Rozdíl je důležitý, protože nález je skutečný a závěr, který z něj lidé vyvozují, bývá příliš konkrétní. Vratnost někde na cestě je mechanismus; odhadnutý formát uložení ne.

Držte důkazy na této úrovni a zbytek posudku zůstane přesný.

Co dokazuje vrácení starého tajemství

Jednosměrný ověřovač nemůže vytvořit původní heslo, protože byl navržen tak, aby nebyl invertovatelný. Pokud služba dokáže heslo poslat e-mailem, pak v tu chvíli drží materiál, ze kterého lze heslo obnovit, nebo zachycuje a ukládá otevřený text před hašováním. V obou případech je cesta obnovy vratná, a to je skutečný bezpečnostní nález. Nic to neříká o tom, zda stejná databáze používá nákladný haš pro jiné sloupce.

Všímejte si i přechodného případu: uložený zašifrovaný blok s klíčem, který drží aplikace, je v praxi vratný, i když slovo zašifrovaný zní ve zprávě uklidňujícím dojmem.

Proč je to nález o návrhu, ne mapa úložiště

E-mail dokazuje obnovitelnost a neidentifikuje přesné schéma. Může jít o otevřený text, deterministické šifrování, rutinu zastírání od dodavatele nebo samostatné úložiště přihlašovacích údajů používané jen k obnově. Různé části produktu často používají různé úložiště. Přiřadit algoritmus na základě jednoho e-mailu je tvrzení, které se na následné schůzce zhroutí.

Co můžete říci, je užší a užitečnější: tato cesta dokáže tajemství obnovit, takže produkt nemůže tvrdit, že neexistují žádné obnovitelné přihlašovací údaje. Všechno další vyžaduje důkazy provozovatele.

Postavte resetování kolem autorizace

Resetování řeší jiný problém: prokázat, že žadatel smí zvolit nové heslo. Pokyny OWASP k tomu popisují bezpečně generované jednorázové tokeny nebo kódy s odpovídající platností a fázi žádosti považují za něco, co je třeba chránit před výčtem a zahlcením. Neověřený požadavek nesmí sám o sobě změnit účet. Ověřte autorizaci před přijetím náhrady a po jednom úspěšném použití token zneplatněte.

E-mailový kanál je součástí bezpečnostního modelu. Vlastnictví názvu účtu nic nedokazuje a tok resetování, který prozrazuje, zda účet existuje, dává útočníkovi adresář, se kterým může pracovat.

Zneplatněte to, co heslo chránilo

Změna hesla automaticky neukončí přístup, který poskytovalo. Aktivní relace VPN, zapamatovaná zařízení a tokeny vydané serverem mohou mít každý vlastní chování při zneplatnění. Vědomě rozhodněte, které z nich musí skončit, a ověřte, že to implementace dělá, protože uživatel, který předpokládá, že ho resetování odhlásilo všude, se často mýlí. Zapište toto rozhodnutí spolu s tokem.

Pro provozovatele: dokumentujte, která komponenta ověřuje požadavek, která mění přihlašovací údaje a jak se zachází se souvisejícími relacemi. Pro uživatele: chraňte legitimní kanál obnovy a každou zprávu, která vrací heslo, považujte za podezřelou.

Přesné hodnocení je krátké: co zpráva dokazuje, co zůstává neznámé a zda obnova nahrazuje přístup řízeným procesem.