Retpoŝto kun pasvorto pruvas renverseblecon, ne skemon

Servo, kiu retpoŝtas la nunan pasvorton de uzanto, pruvis unu aferon: ĝi povas akiri tiun sekreton en formo, kiun ĝi povas sendi. Ĝi ne pruvis, kiun kolumnon, algoritmon aŭ bibliotekon produktis ĝin. La distingo gravas, ĉar la trovaĵo estas reala kaj la konkludo, kiun homoj tiras el ĝi, kutime estas tro specifa. Renversebleco ie en la vojo estas la mekanismo; divenita konservformato ne estas.

Tenu la pruvojn je tiu nivelo, kaj la resto de la revizio restas preciza.

Kion pruvas la resendo de la malnova sekreto

Unudirekta kontrolilo ne povas produkti la originan pasvorton, ĉar ĝi estis desegnita por ne esti inversigebla. Se la servo povas retpoŝti la pasvorton, tiam en tiu momento ĝi tenas materialon, el kiu la pasvorto povas esti reakirita, aŭ ĝi interkaptas kaj konservas la klaran tekston antaŭ hakado. Ĉiel ajn la reakira vojo estas renversebla, kaj tio estas vera sekureca trovaĵo. Ĝi diras nenion pri tio, ĉu la sama datumbazo uzas multekostan hakon por aliaj kolumnoj.

Atentu ankaŭ la interan kazon: konservita ĉifrita blobo kun ŝlosilo tenata de la aplikaĵo estas renversebla en praktiko, eĉ se la vorto ĉifrita sonas trankvilige en raporto.

Kial tio estas trovaĵo pri dezajno, ne mapo de konservado

La retpoŝto pruvas reakireblecon kaj ne identigas la precizan skemon. Ĝi povus esti klara teksto, determinisma ĉifrado, obskuriga rutino de vendisto, aŭ aparta konservejo de akreditaĵoj uzata nur por reakiro. Malsamaj partoj de produkto ofte uzas malsaman konservadon. Asigni algoritmon surbaze de unu retpoŝto estas la speco de aserto, kiu kolapsas en sekva kunveno.

Kion vi povas diri estas pli mallarĝa kaj pli utila: ĉi tiu vojo povas reakiri la sekreton, do la produkto ne povas aserti, ke ne ekzistas reakirebla akreditaĵo. Ĉio pli bezonas la pruvojn de la funkciigisto.

Konstruu la restarigon ĉirkaŭ rajtigo

Restarigo solvas alian problemon: pruvi, ke la petanto rajtas elekti novan pasvorton. La gvidilo de OWASP pri tio priskribas sekure generitajn unu-uzajn ĵetonojn aŭ kodojn kun taŭga findato, kaj ĝi traktas la petan etapon kiel ion protektendan kontraŭ enumerado kaj inundado. Neaŭtentigita peto ne rajtas mem ŝanĝi la konton. Validigu la rajtigon antaŭ ol akcepti la anstataŭigon, kaj faru la ĵetonon neuzebla post unu sukcesa uzo.

La retpoŝta kanalo estas parto de la sekureca modelo. Posedi kontan nomon pruvas nenion, kaj restariga fluo, kiu malkaŝas ĉu konto ekzistas, donas al atakanto konsilon por labori.

Malvalidigu tion, kion la pasvorto protektis

Ŝanĝi pasvorton ne aŭtomate finas la aliron, kiun ĝi donis. Aktivaj VPN-seancaj, memoritaj aparatoj kaj ĵetonoj eldonitaj de la servilo povas ĉiu havi sian propran malvalidigan konduton. Decidu konscie, kiuj el ili devas finiĝi, kaj kontrolu, ke la efektivigo faras tion, ĉar uzanto, kiu supozas, ke restarigo elsalutis lin ĉie, ofte malpravas. Registru tiun decidon kune kun la fluo.

Por funkciigistoj: dokumentu, kiu komponanto kontrolas la peton, kiu ŝanĝas la akreditaĵon kaj kiel rilataj seancoj traktiĝas. Por uzantoj: protektu la legitiman reakiran kanalon kaj traktu ajnan mesaĝon, kiu resendas pasvorton, kiel suspektindan.

La preciza takso estas mallonga: kion la mesaĝo pruvas, kio restas nekonata, kaj ĉu reakiro anstataŭas aliron per kontrolita procezo.