En e-mail med adgangskoden beviser reversibilitet, ikke et skema

En tjeneste, der sender en brugers nuværende adgangskode via e-mail, har bevist én ting: den kan skaffe den hemmelighed i en form, den kan sende. Den har ikke bevist, hvilken kolonne, algoritme eller bibliotek der frembragte den. Forskellen er vigtig, fordi fundet er reelt, og den konklusion, folk drager af det, er som regel for specifik. Reversibilitet et eller andet sted i forløbet er mekanismen; et gættet lagerformat er det ikke.

Hold beviserne på det niveau, og resten af gennemgangen forbliver præcis.

Hvad det at sende den gamle hemmelighed tilbage beviser

En envejsverifikator kan ikke frembringe den oprindelige adgangskode, fordi den blev designet til ikke at kunne inverteres. Hvis tjenesten kan sende adgangskoden via e-mail, så ligger den i det øjeblik inde med materiale, hvorfra adgangskoden kan gendannes, eller den opsnapper og gemmer klarteksten før hashning. Under alle omstændigheder er gendannelsesvejen reversibel, og det er et reelt sikkerhedsfund. Det siger intet om, hvorvidt den samme database bruger en dyr hash til andre kolonner.

Læg også mærke til mellemtilfældet: en gemt krypteret blob med en nøgle, som applikationen holder, er reversibel i praksis, selv om ordet krypteret lyder betryggende i en rapport.

Hvorfor det er et designfund og ikke et lagerkort

E-mailen beviser gendannelighed og identificerer ikke det præcise skema. Det kan være klartekst, deterministisk kryptering, en leverandørs sløringsroutine eller et separat legitimationslager, der kun bruges til gendannelse. Forskellige dele af et produkt bruger ofte forskellig lagring. At tildele en algoritme på grundlag af én e-mail er den slags påstand, der falder sammen på et opfølgende møde.

Det, du kan sige, er smallere og mere nyttigt: denne vej kan gendanne hemmeligheden, så produktet kan ikke hævde, at der ikke findes nogen gendannelig legitimationsoplysning. Alt derudover kræver operatørens beviser.

Byg nulstillingen omkring autorisation

En nulstilling løser et andet problem: at bevise, at anmoderen må vælge en ny adgangskode. OWASPs vejledning om dette beskriver sikkert genererede engangstokens eller -koder med en passende udløbsperiode og behandler anmodningsfasen som noget, der skal beskyttes mod optælling og oversvømmelse. En uautentificeret anmodning må ikke ændre kontoen af sig selv. Valider autorisationen, før du accepterer erstatningen, og gør tokenet ubrugeligt efter én vellykket brug.

E-mailkanalen er en del af sikkerhedsmodellen. At besidde et kontonavn beviser intet, og et nulstillingsforløb, der afslører, om en konto findes, giver en angriber en fortegnelse at arbejde ud fra.

Ugyldiggør det, som adgangskoden beskyttede

At ændre en adgangskode afslutter ikke automatisk den adgang, den gav. Aktive VPN-sessioner, huskede enheder og tokens udstedt af serveren kan hver have deres egen ugyldiggørelsesadfærd. Beslut bevidst, hvilke af dem der skal slutte, og verificér, at implementeringen gør det, fordi en bruger, der antager, at en nulstilling loggede dem ud overalt, ofte tager fejl. Notér den beslutning sammen med forløbet.

For operatører: dokumentér, hvilken komponent der verificerer anmodningen, hvilken der ændrer legitimationsoplysningen, og hvordan relaterede sessioner håndteres. For brugere: beskyt den legitime gendannelseskanal, og behandl enhver meddelelse, der returnerer en adgangskode, som mistænkelig.

Den præcise vurdering er kort: hvad meddelelsen beviser, hvad der forbliver ukendt, og om gendannelse erstatter adgang gennem en kontrolleret proces.