Ein e-post med passordet provar reversibilitet, ikkje eit skjema

Ein teneste som sender det gjeldande passordet til ein brukar på e-post, har prova éin ting: ho kan skaffe denne løyndomen i ei form ho kan sende. Ho har ikkje prova kva kolonne, algoritme eller bibliotek som laga han. Skilnaden er viktig fordi funnet er reelt, og konklusjonen folk dreg av det, er vanlegvis for spesifikk. Reversibilitet ein stad i løpet er mekanismen; eit gjette lagringsformat er det ikkje.

Hald prova på det nivået, og resten av gjennomgangen held seg nøyaktig.

Kva det å sende den gamle løyndomen tilbake provar

Ein einvegs verifikator kan ikkje produsere det opphavlege passordet, fordi han vart forma slik at han ikkje er inverterbar. Viss tenesta kan sende passordet på e-post, har ho i det augneblinken materiale som passordet kan gjenopprettast frå, eller ho fangar opp og lagrar klarteksten før hashing. Uansett er gjenopprettingsvegen reversibel, og det er eit reelt tryggleiksfunn. Det seier ingenting om same database brukar ein kostbar hash for andre kolonnar.

Legg òg merke til mellomtilfellet: ein lagra kryptert blob med ein nøkkel applikasjonen held, er reversibel i praksis, sjølv om ordet kryptert høyrest trygt ut i ein rapport.

Kvifor det er eit formgjevingsfunn og ikkje eit lagringskart

E-posten provar gjenopprettbarheit og identifiserer ikkje det nøyaktige skjemaet. Det kan vere klartekst, deterministisk kryptering, ein sløringsroutine frå ein leverandør eller eit eige lager for påloggingsinformasjon som berre vert brukt til gjenoppretting. Ulike delar av eit produkt brukar ofte ulik lagring. Å tildele ein algoritme på grunnlag av éin e-post er den typen påstand som fell saman i eit oppfølgingsmøte.

Det du kan seie, er smalare og meir nyttig: denne vegen kan gjenopprette løyndomen, så produktet kan ikkje hevde at det ikkje finst gjenopprettbar påloggingsinformasjon. Alt utover det krev prova til operatøren.

Bygg tilbakestillinga kring autorisasjon

Ei tilbakestilling løyser eit anna problem: å prove at den som ber om det, kan velje eit nytt passord. OWASP sine retningslinjer om dette skildrar trygt genererte eingongstoken eller kodar med passande utløp, og behandlar førespurnadsfasen som noko som skal vernast mot oppteljing og overflod. Ein uautentisert førespurnad må ikkje endre kontoen av seg sjølv. Valider autorisasjonen før du godtek erstatninga, og gjer tokenet ubrukeleg etter éin vellukka bruk.

E-postkanalen er ein del av tryggleiksmodellen. Å ha eit kontonamn provar ingenting, og ein tilbakestillingsflyt som avdekkjer om ein konto finst, gjev ein åtakar ei forteikning å arbeide ut frå.

Gjer ugyldig det passordet verna

Å endre eit passord avsluttar ikkje automatisk tilgangen det gav. Aktive VPN-øktar, hugsa einingar og token som serveren gjev ut, kan kvar ha si eiga ugyldiggjeringåtferd. Avgjer medvite kva av dei som må avsluttast, og stadfest at implementasjonen gjer det, fordi ein brukar som trur at ei tilbakestilling logga han ut overalt, tek ofte feil. Skriv ned den avgjerda saman med flyten.

For operatørar: dokumenter kva komponent som stadfestar førespurnaden, kven som endrar påloggingsinformasjonen og korleis relaterte øktar vert handsama. For brukarar: vern den legitime gjenopprettingskanalen og handsam kvar melding som returnerer eit passord, som mistenkeleg.

Den presise vurderinga er kort: kva meldinga provar, kva som er ukjent og om gjenoppretting erstattar tilgang gjennom ein kontrollert prosess.