Ett e-postmeddelande med lösenordet bevisar reversibilitet, inte ett schema

En tjänst som mejlar en användares nuvarande lösenord har bevisat en sak: den kan få tag i hemligheten i en form den kan skicka. Den har inte bevisat vilken kolumn, algoritm eller vilket bibliotek som producerade den. Skillnaden spelar roll eftersom fyndet är verkligt och slutsatsen folk drar av det oftast är för specifik. Reversibilitet någonstans i kedjan är mekanismen; ett gissat lagringsformat är det inte.

Håll bevisen på den nivån, och resten av granskningen förblir korrekt.

Vad det att skicka tillbaka den gamla hemligheten bevisar

En enkelriktad verifierare kan inte producera det ursprungliga lösenordet, eftersom den konstruerades för att inte vara inverterbar. Om tjänsten kan mejla lösenordet har den i det ögonblicket material som lösenordet kan återställas från, eller så fångar den upp och lagrar klartexten före hashningen. Hur som helst är återställningsvägen reversibel, och det är ett verkligt säkerhetsfynd. Det säger ingenting om huruvida samma databas använder en dyr hash för andra kolumner.

Notera också mellanfallet: en lagrad krypterad blob med en nyckel som applikationen har är reversibel i praktiken, även om ordet krypterad låter betryggande i en rapport.

Varför det är ett designfynd och inte en lagringskarta

E-postmeddelandet bevisar återställbarhet och identifierar inte det exakta schemat. Det kan vara klartext, deterministisk kryptering, en leverantörs oskärperutin eller ett separat lager för inloggningsuppgifter som bara används för återställning. Olika delar av en produkt använder ofta olika lagring. Att tillskriva en algoritm utifrån ett enda mejl är den typ av påstående som faller ihop på nästa möte.

Det du kan säga är snävare och mer användbart: den här vägen kan återställa hemligheten, så produkten kan inte hävda att det inte finns några återställbara inloggningsuppgifter. Allt därutöver kräver operatörens bevis.

Bygg återställningen kring auktorisering

En återställning löser ett annat problem: att bevisa att den som begär det får välja ett nytt lösenord. OWASPs vägledning om detta beskriver säkert genererade engångstoken eller koder med lämplig giltighetstid, och behandlar begäransfasen som något som ska skyddas mot uppräkning och överflöd. En oautentiserad begäran får inte ändra kontot av sig själv. Validera auktoriseringen innan du accepterar ersättningen, och gör tokenet oanvändbart efter en lyckad användning.

E-postkanalen är en del av säkerhetsmodellen. Att inneha ett kontonamn bevisar ingenting, och ett återställningsflöde som avslöjar om ett konto finns ger en angripare en förteckning att arbeta utifrån.

Ogiltigförklara det lösenordet skyddade

Att byta lösenord avslutar inte automatiskt den åtkomst det gav. Aktiva VPN-sessioner, ihågkomna enheter och tokens som utfärdas av servern kan ha var sitt ogiltigförklarandebeteende. Bestäm medvetet vilka av dem som måste avslutas, och verifiera att implementeringen gör det, eftersom en användare som antar att en återställning loggade ut dem överallt ofta har fel. Anteckna det beslutet tillsammans med flödet.

För operatörer: dokumentera vilken komponent som verifierar begäran, vilken som ändrar inloggningsuppgiften och hur relaterade sessioner hanteras. För användare: skydda den legitima återställningskanalen och behandla varje meddelande som returnerar ett lösenord som misstänkt.

Den exakta bedömningen är kort: vad meddelandet bevisar, vad som förblir okänt och om återställning ersätter åtkomst genom en kontrollerad process.