E-pošta s lozinkom dokazuje povrativost, a ne shemu

Servis koji šalje trenutnu lozinku korisnika e-poštom dokazao je jedno: može doći do te tajne u obliku koji može poslati. Nije dokazao koji su je stupac, algoritam ili biblioteka stvorili. Razlika je važna jer je nalaz stvaran, a zaključak koji ljudi iz njega izvlače obično je previše konkretan. Povrativost negdje na putu je mehanizam; nagađani format pohrane nije.

Zadržite dokaze na tom nivou i ostatak pregleda ostaje tačan.

Šta dokazuje vraćanje stare tajne

Jednosmjerni verifikator ne može proizvesti izvornu lozinku jer je dizajniran tako da ne bude invertibilan. Ako servis može poslati lozinku e-poštom, tada u tom trenutku drži materijal iz kojeg se lozinka može vratiti, ili presreće i čuva čisti tekst prije heširanja. U svakom slučaju put oporavka je povrativ, i to je stvarni sigurnosni nalaz. To ne govori ništa o tome koristi li ista baza podataka skupi heš za druge stupce.

Obratite pažnju i na srednji slučaj: pohranjeni šifrirani blob s ključem koji drži aplikacija u praksi je povrativ, iako riječ šifrirano u izvještaju zvuči umirujuće.

Zašto je to nalaz o dizajnu, a ne mapa pohrane

E-pošta dokazuje mogućnost oporavka i ne identifikuje tačnu shemu. Može biti čisti tekst, determinističko šifriranje, rutina zamagljivanja dobavljača ili odvojeno spremište akreditiva koje se koristi samo za oporavak. Različiti dijelovi proizvoda često koriste različitu pohranu. Dodijeliti algoritam na osnovu jedne e-pošte vrsta je tvrdnje koja se raspada na sljedećem sastanku.

Ono što možete reći uže je i korisnije: ovaj put može vratiti tajnu, pa proizvod ne može tvrditi da nema povrativih akreditiva. Sve izvan toga traži dokaze operatera.

Gradite resetovanje oko autorizacije

Resetovanje rješava drugi problem: dokazivanje da podnosilac zahtjeva smije izabrati novu lozinku. OWASP-ove smjernice za to opisuju sigurno generirane tokene ili kodove za jednokratnu upotrebu s odgovarajućim rokom trajanja i tretiraju fazu zahtjeva kao nešto što treba zaštititi od nabrajanja i preplavljivanja. Neautentificirani zahtjev ne smije sam po sebi promijeniti račun. Provjerite autorizaciju prije prihvatanja zamjene i učinite token neupotrebljivim nakon jedne uspješne upotrebe.

Kanal e-pošte dio je sigurnosnog modela. Posjedovanje naziva računa ništa ne dokazuje, a tok resetovanja koji otkriva postoji li račun daje napadaču imenik s kojim može raditi.

Poništite ono što je lozinka štitila

Promjena lozinke ne prekida automatski pristup koji je omogućila. Aktivne VPN sesije, zapamćeni uređaji i tokeni koje izdaje server mogu imati vlastito ponašanje poništavanja. Svjesno odlučite koje od njih moraju prestati i provjerite da implementacija to čini, jer korisnik koji pretpostavlja da ga je resetovanje odjavilo svuda često griješi. Zapišite tu odluku uz tok.

Za operatere: dokumentirajte koja komponenta provjerava zahtjev, koja mijenja akreditive i kako se obrađuju povezane sesije. Za korisnike: zaštitite legitimni kanal oporavka i tretirajte svaku poruku koja vraća lozinku kao sumnjivu.

Precizna procjena je kratka: šta poruka dokazuje, šta ostaje nepoznato i zamjenjuje li oporavak pristup kroz kontrolirani proces.