Egy jelszót tartalmazó e-mail a visszafordíthatóságot bizonyítja, nem egy sémát

Egy szolgáltatás, amely e-mailben elküldi a felhasználó jelenlegi jelszavát, egy dolgot bizonyított: meg tudja szerezni ezt a titkot olyan formában, amelyet el tud küldeni. Azt nem bizonyította, hogy melyik oszlop, algoritmus vagy könyvtár állította elő. A különbség számít, mert a megállapítás valós, és a belőle levont következtetés általában túl konkrét. A visszafordíthatóság valahol az útvonalon a mechanizmus; egy feltételezett tárolási formátum nem az.

Tartsd a bizonyítékokat ezen a szinten, és az értékelés többi része pontos marad.

Mit bizonyít a régi titok visszaküldése

Az egyirányú ellenőrző nem tudja előállítani az eredeti jelszót, mert úgy tervezték, hogy ne legyen megfordítható. Ha a szolgáltatás el tudja küldeni a jelszót e-mailben, akkor abban a pillanatban olyan anyagot tart, amelyből a jelszó visszanyerhető, vagy elfogja és tárolja a nyílt szöveget a hashelés előtt. Mindkét esetben a visszanyerési útvonal megfordítható, és ez valódi biztonsági megállapítás. Ez semmit sem mond arról, hogy ugyanaz az adatbázis költséges hasht használ-e más oszlopokhoz.

Figyelj a köztes esetre is: az alkalmazás birtokában lévő kulccsal tárolt titkosított blob a gyakorlatban megfordítható, még ha a titkosított szó megnyugtatóan is hangzik egy jelentésben.

Miért tervezési megállapítás ez, és nem tárolási térkép

Az e-mail bizonyítja a visszanyerhetőséget, és nem azonosítja a pontos sémát. Lehet nyílt szöveg, determinisztikus titkosítás, egy szállító elhomályosító rutinja vagy külön hitelesítőadat-tár, amelyet csak visszanyerésre használnak. Egy termék különböző részei gyakran különböző tárolást használnak. Egyetlen e-mail alapján algoritmust tulajdonítani olyan állítás, amely a következő megbeszélésen összeomlik.

Amit mondhatsz, az szűkebb és hasznosabb: ez az útvonal vissza tudja nyerni a titkot, tehát a termék nem állíthatja, hogy nincs visszanyerhető hitelesítő adat. Minden ezen túl az üzemeltető bizonyítékait igényli.

Építsd a visszaállítást az engedélyezés köré

A visszaállítás más problémát old meg: annak bizonyítását, hogy a kérelmező választhat új jelszót. Az OWASP erről szóló útmutatása biztonságosan generált, egyszer használatos tokeneket vagy kódokat ír le megfelelő lejárattal, és a kérelem szakaszát olyasvalamiként kezeli, amit védeni kell a felsorolás és az elárasztás ellen. Egy hitelesítetlen kérelem önmagában nem változtathatja meg a fiókot. A helyettesítés elfogadása előtt érvényesítsd az engedélyezést, és egy sikeres használat után tedd a tokent használhatatlanná.

Az e-mail csatorna a biztonsági modell része. Egy fióknév birtoklása semmit sem bizonyít, és az a visszaállítási folyamat, amely felfedi, létezik-e a fiók, útmutatót ad a támadónak a munkához.

Érvénytelenítsd, amit a jelszó védett

A jelszó megváltoztatása nem szünteti meg automatikusan az általa adott hozzáférést. Az aktív VPN-munkameneteknek, a megjegyzett eszközöknek és a kiszolgáló által kiadott tokeneknek külön-külön lehet saját érvénytelenítési viselkedésük. Döntsd el szándékosan, melyiküknek kell véget érnie, és ellenőrizd, hogy a megvalósítás ezt teszi, mert az a felhasználó, aki feltételezi, hogy egy visszaállítás mindenhonnan kijelentkeztette, gyakran téved. Jegyezd fel ezt a döntést a folyamattal együtt.

Üzemeltetőknek: dokumentáld, melyik összetevő ellenőrzi a kérelmet, melyik változtatja meg a hitelesítő adatot, és hogyan kezelik a kapcsolódó munkameneteket. Felhasználóknak: védd a jogszerű visszanyerési csatornát, és kezeld gyanúsnak minden olyan üzenetet, amely jelszót küld vissza.

A pontos értékelés rövid: mit bizonyít az üzenet, mi marad ismeretlen, és hogy a visszanyerés ellenőrzött folyamaton keresztül helyettesíti-e a hozzáférést.