Ang email ng password ay nagpapatunay ng pagbalik, hindi ng scheme

Ang serbisyong nag-email ng kasalukuyang password ng isang user ay nagpatunay ng isang bagay: makukuha nito ang lihim na iyon sa anyong maipapadala nito. Hindi nito napatunayan kung aling column, algorithm o library ang gumawa niyon. Mahalaga ang pagkakaiba dahil totoo ang natuklasan at ang konklusyong hinihila ng mga tao mula rito ay karaniwang masyadong tiyak. Ang pagbalik sa isang punto ng landas ang mekanismo; ang hinulaang storage format ay hindi.

Panatilihin ang ebidensya sa ganoong antas, at mananatiling tumpak ang natitirang bahagi ng pagsusuri.

Ano ang napatutunayan ng pagpapadala pabalik ng lumang lihim

Hindi makagawa ang one-way verifier ng orihinal na password, dahil idinisenyo ito para hindi mabaliktad. Kung maipapadala ng serbisyo ang password sa email, sa sandaling iyon may hawak itong materyal na makukuha mula roon ang password, o hinuhuli at iniimbak nito ang plaintext bago ang hashing. Sa alinmang paraan, ang landas ng pagbawi ay nababaliktad, at iyon ay tunay na natuklasang pangseguridad. Wala itong sinasabi tungkol sa kung ang parehong database ay gumagamit ng mamahaling hash para sa ibang column.

Pansinin din ang gitnang kaso: ang naka-imbak na encrypted blob na may key na hawak ng application ay nababaliktad sa praktika, kahit ang salitang encrypted ay parang nakapapanatag sa isang ulat.

Bakit ito natuklasang disenyo, hindi mapa ng imbakan

Napatutunayan ng email ang kakayahang makabawi at hindi tinutukoy ang eksaktong scheme. Maaaring plaintext ito, deterministikong encryption, routine ng pag-obscure ng vendor, o hiwalay na imbakan ng kredensyal na ginagamit lamang para sa pagbawi. Madalas gumamit ng iba't ibang imbakan ang iba't ibang bahagi ng isang produkto. Ang pagtatalaga ng algorithm batay sa isang email ay ang uri ng pahayag na gumuguho sa susunod na pulong.

Ang masasabi mo ay mas makitid at mas kapaki-pakinabang: makakabawi ang landas na ito ng lihim, kaya hindi maaaring mag-angkin ang produkto na walang makukuhang kredensyal. Lahat ng higit doon ay nangangailangan ng ebidensya ng operator.

Itayo ang reset sa paligid ng awtorisasyon

Ang reset ay lumulutas ng ibang problema: patunayan na ang humihiling ay maaaring pumili ng bagong password. Inilalarawan ng gabay ng OWASP tungkol dito ang ligtas na nabuong one-time token o code na may naaangkop na pagtatapos, at tinatrato ang yugto ng hiling bilang isang bagay na dapat protektahan laban sa enumerasyon at pagbaha. Hindi dapat baguhin ng hindi awtentikadong hiling ang account nang mag-isa. I-validate ang awtorisasyon bago tanggapin ang kapalit, at gawing hindi magagamit ang token pagkatapos ng isang matagumpay na paggamit.

Ang email channel ay bahagi ng modelo ng seguridad. Ang pagkakaroon ng pangalan ng account ay hindi nagpapatunay ng anuman, at ang daloy ng reset na nagsisiwalat kung may account ay nagbibigay sa attacker ng direktoryo na pagtatrabahuhan.

Imbalido ang pinrotektahan ng password

Ang pagpapalit ng password ay hindi awtomatikong nagtatapos sa access na ibinigay nito. Ang aktibong sesyon ng VPN, naaalalang device at token na ibinibigay ng server ay maaaring may kanya-kanyang pag-uugali sa pag-imbalido. Sadyang magpasya kung alin sa mga ito ang dapat magtapos, at i-verify na ginagawa ito ng implementasyon, dahil ang user na nag-aakalang ang reset ay nag-log out sa kanya sa lahat ng lugar ay madalas nagkakamali. Itala ang pasyang iyon kasama ng daloy.

Para sa mga operator: idokumento kung aling component ang nagbe-verify ng hiling, alin ang nagbabago ng kredensyal at paano hinahawakan ang kaugnay na sesyon. Para sa mga user: protektahan ang lehitimong channel ng pagbawi at ituring na kahina-hinala ang anumang mensaheng nagbabalik ng password.

Ang tumpak na pagtatasa ay maikli: ano ang napatutunayan ng mensahe, ano ang nananatiling hindi alam, at kung pinapalitan ng pagbawi ang access sa pamamagitan ng kontroladong proseso.