Mejl sa lozinkom dokazuje povrativost, a ne šemu

Servis koji mejlom šalje trenutnu lozinku korisnika dokazao je jedno: može doći do te tajne u obliku koji može poslati. Nije dokazao koji su je stubac, 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 negde na putu je mehanizam; nagađani format skladištenja nije.

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

Šta dokazuje vraćanje stare tajne

Jednosmerni verifikator ne može proizvesti izvornu lozinku jer je dizajniran tako da ne bude invertibilan. Ako servis može poslati lozinku mejlom, tada u tom trenutku drži materijal iz kojeg se lozinka može vratiti, ili presreće i čuva čist tekst pre 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 stubce.

Obratite pažnju i na srednji slučaj: sačuvan šifriran blob sa ključem koji drži aplikacija u praksi je povrativ, iako reč šifrirano u izveštaju zvuči umirujuće.

Zašto je to nalaz o dizajnu, a ne mapa skladištenja

Mejl dokazuje mogućnost oporavka i ne identifikuje tačnu šemu. Može biti čist tekst, determinističko šifriranje, rutina zamućivanja dobavljača ili odvojeno skladište akreditiva koje se koristi samo za oporavak. Različiti delovi proizvoda često koriste različito skladištenje. Dodeliti algoritma na osnovu jednog mejla vrsta je tvrdnje koja se raspada na sledeć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 rešava drugi problem: dokazivanje da podnosilac zahteva sme da izabere novu lozinku. OWASP smernice za to opisuju bezbedno generisane tokene ili kodove za jednokratnu upotrebu s odgovarajućim rokom trajanja i tretiraju fazu zahteva kao nešto što treba zaštititi od nabrajanja i preplavljivanja. Neautentifikovani zahtev ne sme sam po sebi promeniti račun. Proverite autorizaciju pre prihvatanja zamene i učinite token neupotrebljivim posle jedne uspešne upotrebe.

Mejl kanal je deo sigurnosnog modela. Posedovanje 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

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

Za operatere: dokumentujte koja komponenta proverava zahtev, koja menja 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 procena je kratka: šta poruka dokazuje, šta ostaje nepoznato i zamenjuje li oporavak pristup kroz kontrolisani proces.