Një e-mail me fjalëkalim provon kthyeshmërinë, jo një skemë

Një shërbim që dërgon me e-mail fjalëkalimin aktual të një përdoruesi ka provuar një gjë: mund ta marrë atë sekret në një formë që mund ta dërgojë. Nuk ka provuar cila kolonë, algoritëm apo bibliotekë e prodhoi atë. Dallimi ka rëndësi, sepse gjetja është reale dhe përfundimi që njerëzit nxjerrin prej saj zakonisht është tepër i saktë. Kthyeshmëria diku në rrugë është mekanizmi; një format ruajtjeje i hamendësuar nuk është.

Mbajini provat në atë nivel dhe pjesa tjetër e rishikimit mbetet e saktë.

Çfarë provon kthimi i sekretit të vjetër

Një verifikues njëdrejtimësh nuk mund të prodhojë fjalëkalimin origjinal, sepse është dizajnuar të mos jetë i kthyeshëm. Nëse shërbimi mund ta dërgojë fjalëkalimin me e-mail, atëherë në atë moment mban material nga i cili fjalëkalimi mund të rikuperohet, ose e kap dhe e ruan tekstin e thjeshtë përpara hashimit. Në çdo rast, rruga e rikuperimit është e kthyeshme, dhe kjo është një gjetje e vërtetë sigurie. Ajo nuk thotë asgjë për atë nëse e njëjta bazë të dhënash përdor një hash të kushtueshëm për kolona të tjera.

Vini re edhe rastin e ndërmjetëm: një blob i kriptuar i ruajtur me një çelës që mbahet nga aplikacioni është i kthyeshëm në praktikë, edhe pse fjala e kriptuar tingëllon qetësuese në një raport.

Pse është gjetje dizajni, jo hartë e ruajtjes

E-maili provon rikuperueshmërinë dhe nuk identifikon skemën e saktë. Mund të jetë tekst i thjeshtë, kriptim deterministik, një rutinë errësimi e një furnizuesi ose një depo e veçantë kredencialesh që përdoret vetëm për rikuperim. Pjesë të ndryshme të një produkti shpesh përdorin ruajtje të ndryshme. T'i atribuosh një algoritëm bazuar në një e-mail të vetëm është lloji i pohimit që rrënohet në mbledhjen e radhës.

Ajo që mund të thoni është më e ngushtë dhe më e dobishme: kjo rrugë mund ta rikuperojë sekretin, prandaj produkti nuk mund të pretendojë se nuk ekziston asnjë kredencial i rikuperueshëm. Çdo gjë përtej kësaj kërkon provat e operatorit.

Ndërtoni rivendosjen rreth autorizimit

Një rivendosje zgjidh një problem tjetër: të provojë se kërkuesi mund të zgjedhë një fjalëkalim të ri. Udhëzimi i OWASP për këtë përshkruan tokena ose kode njëpërdorimësh të gjeneruara në mënyrë të sigurt me një skadim të përshtatshëm, dhe e trajton fazën e kërkesës si diçka që duhet mbrojtur nga numërimi dhe nga përmbytja. Një kërkesë e paautentikuar nuk duhet ta ndryshojë llogarinë vetë. Validoni autorizimin përpara se të pranoni zëvendësimin, dhe bëjeni tokenin të papërdorshëm pas një përdorimi të suksesshëm.

Kanali i e-mailit është pjesë e modelit të sigurisë. Zotërimi i një emri llogarie nuk provon asgjë, dhe një rrjedhë rivendosjeje që zbulon nëse një llogari ekziston i jep sulmuesit një drejtori për të punuar.

Anuloni atë që mbronte fjalëkalimi

Ndryshimi i një fjalëkalimi nuk e përfundon automatikisht aksesin që jepte. Sesionet aktive VPN, pajisjet e mbajtura mend dhe tokenat e lëshuara nga serveri mund të kenë secili sjelljen e vet të anulimit. Vendosni me qëllim cilat prej tyre duhet të përfundojnë, dhe verifikoni që implementimi e bën këtë, sepse një përdorues që supozon se rivendosja e ka shkëputur kudo shpesh gabon. Regjistroni atë vendim bashkë me rrjedhën.

Për operatorët: dokumentoni cili komponent verifikon kërkesën, cili ndryshon kredencialin dhe si trajtohen sesionet e lidhura. Për përdoruesit: mbroni kanalin legjitim të rikuperimit dhe trajtojeni çdo mesazh që kthen një fjalëkalim si të dyshimtë.

Vlerësimi i saktë është i shkurtër: çfarë provon mesazhi, çfarë mbetet e panjohur dhe nëse rikuperimi e zëvendëson aksesin përmes një procesi të kontrolluar.