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

Servis koji šalje trenutačnu 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 jest mehanizam; nagađani format pohrane nije.

Zadržite dokaze na toj razini i ostatak pregleda ostaje točan.

Što 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 rabi li ista baza podataka skupi heš za druge stupce.

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

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

E-pošta dokazuje mogućnost oporavka i ne identificira točnu shemu. Može biti čisti tekst, determinističko šifriranje, rutina zamagljivanja dobavljača ili odvojeno spremište akreditiva koje se rabi samo za oporavak. Različiti dijelovi proizvoda često rabe različitu pohranu. Dodijeliti algoritam na temelju 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 poništavanje oko autorizacije

Poništavanje rješava drugi problem: dokazivanje da podnositelj zahtjeva smije izabrati novu lozinku. OWASP-ove smjernice za to opisuju sigurno generirane tokene ili kodove za jednokratnu uporabu 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 prihvaćanja zamjene i učinite token neupotrebljivim nakon jedne uspješne uporabe.

Kanal e-pošte dio je sigurnosnog modela. Posjedovanje naziva računa ništa ne dokazuje, a tok poništavanja 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 poslužitelj 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 poništavanje odjavilo svugdje č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: što poruka dokazuje, što ostaje nepoznato i zamjenjuje li oporavak pristup kroz kontrolirani proces.