En e-post med passordet beviser reversibilitet, ikke et skjema

En tjeneste som sender brukerens gjeldende passord på e-post, har bevist én ting: den kan skaffe denne hemmeligheten i en form den kan sende. Den har ikke bevist hvilken kolonne, algoritme eller bibliotek som produserte den. Forskjellen er viktig fordi funnet er reelt, og konklusjonen folk trekker av det, er vanligvis for spesifikk. Reversibilitet et sted i løpet er mekanismen; et gjettet lagringsformat er det ikke.

Hold bevisene på det nivået, og resten av gjennomgangen forblir nøyaktig.

Hva det å sende den gamle hemmeligheten tilbake beviser

En enveis verifikator kan ikke produsere det opprinnelige passordet, fordi den ble utformet for ikke å være inverterbar. Hvis tjenesten kan sende passordet på e-post, har den i det øyeblikket materiale som passordet kan gjenopprettes fra, eller den fanger opp og lagrer klarteksten før hashing. Uansett er gjenopprettingsveien reversibel, og det er et reelt sikkerhetsfunn. Det sier ingenting om hvorvidt samme database bruker en kostbar hash for andre kolonner.

Legg også merke til mellomtilfellet: en lagret kryptert blob med en nøkkel applikasjonen holder, er reversibel i praksis, selv om ordet kryptert høres betryggende ut i en rapport.

Hvorfor det er et designfunn og ikke et lagringskart

E-posten beviser gjenopprettbarhet og identifiserer ikke det nøyaktige skjemaet. Det kan være klartekst, deterministisk kryptering, en leverandørs sløringsroutine eller et eget lager for påloggingsinformasjon som bare brukes til gjenoppretting. Ulike deler av et produkt bruker ofte ulik lagring. Å tildele en algoritme på grunnlag av én e-post er den typen påstand som faller sammen i et oppfølgingsmøte.

Det du kan si, er smalere og mer nyttig: denne veien kan gjenopprette hemmeligheten, så produktet kan ikke hevde at det ikke finnes noen gjenopprettbar påloggingsinformasjon. Alt utover det krever operatørens bevis.

Bygg tilbakestillingen rundt autorisasjon

En tilbakestilling løser et annet problem: å bevise at den som ber om det, kan velge et nytt passord. OWASPs veiledning om dette beskriver sikkert genererte engangstokens eller koder med passende utløp, og behandler forespørselsfasen som noe som skal beskyttes mot opptelling og overflom. En uautentisert forespørsel må ikke endre kontoen av seg selv. Valider autorisasjonen før du godtar erstatningen, og gjør tokenet ubrukelig etter én vellykket bruk.

E-postkanalen er en del av sikkerhetsmodellen. Å ha et kontonavn beviser ingenting, og en tilbakestillingsflyt som avslører om en konto finnes, gir en angriper en fortegnelse å arbeide ut fra.

Ugyldiggjør det passordet beskyttet

Å endre et passord avslutter ikke automatisk tilgangen det ga. Aktive VPN-økter, huskede enheter og tokens utstedt av serveren kan hver ha sin egen ugyldiggjøringsatferd. Bestem bevisst hvilke av dem som må avsluttes, og verifiser at implementasjonen gjør det, fordi en bruker som antar at en tilbakestilling logget dem ut overalt, ofte tar feil. Noter den beslutningen sammen med flyten.

For operatører: dokumenter hvilken komponent som verifiserer forespørselen, hvilken som endrer påloggingsinformasjonen og hvordan relaterte økter håndteres. For brukere: beskytt den legitime gjenopprettingskanalen og behandle enhver melding som returnerer et passord, som mistenkelig.

Den presise vurderingen er kort: hva meldingen beviser, hva som forblir ukjent, og om gjenoppretting erstatter tilgang gjennom en kontrollert prosess.