Een wachtwoord-e-mail bewijst omkeerbaarheid, geen schema

Een dienst die het huidige wachtwoord van een gebruiker per e-mail verstuurt, heeft één ding bewezen: hij kan dat geheim verkrijgen in een vorm die hij kan versturen. Hij heeft niet bewezen welke kolom, welk algoritme of welke bibliotheek het heeft geproduceerd. Het onderscheid is belangrijk omdat de bevinding echt is en de conclusie die mensen eruit trekken meestal te specifiek is. Omkeerbaarheid ergens in het pad is het mechanisme; een geraden opslagformaat is dat niet.

Houd het bewijs op dat niveau, en de rest van de beoordeling blijft accuraat.

Wat het terugsturen van het oude geheim bewijst

Een eenrichtingsverificatie kan het oorspronkelijke wachtwoord niet produceren, omdat het is ontworpen om niet omkeerbaar te zijn. Als de dienst het wachtwoord per e-mail kan versturen, dan heeft hij op dat moment materiaal waaruit het wachtwoord kan worden hersteld, of hij onderschept en bewaart de platte tekst voordat er wordt gehasht. Hoe dan ook is het herstelpad omkeerbaar, en dat is een echte beveiligingsbevinding. Het zegt niets over de vraag of dezelfde database voor andere kolommen een dure hash gebruikt.

Let ook op het tussenliggende geval: een opgeslagen versleutelde blob met een sleutel die de applicatie bezit, is in de praktijk omkeerbaar, ook al klinkt het woord versleuteld geruststellend in een rapport.

Waarom dat een ontwerpbevinding is en geen opslagkaart

De e-mail bewijst herstelbaarheid en identificeert niet het exacte schema. Het kan platte tekst zijn, deterministische versleuteling, een obfuscatie-routine van een leverancier of een aparte opslag van inloggegevens die alleen voor herstel wordt gebruikt. Verschillende delen van een product gebruiken vaak verschillende opslag. Een algoritme toeschrijven op basis van één e-mail is het soort bewering dat in een vervolgoverleg instort.

Wat je kunt zeggen is smaller en nuttiger: dit pad kan het geheim herstellen, dus het product kan niet beweren dat er geen herstelbare inloggegevens bestaan. Al het andere vereist het bewijs van de operator.

Bouw de reset rond autorisatie

Een reset lost een ander probleem op: bewijzen dat de aanvrager een nieuw wachtwoord mag kiezen. De richtlijnen van OWASP hierover beschrijven veilig gegenereerde eenmalige tokens of codes met een passende vervaldatum, en behandelen de aanvraagfase als iets dat tegen enumeratie en overstroming moet worden beschermd. Een niet-geauthenticeerd verzoek mag het account niet op zichzelf wijzigen. Valideer de autorisatie voordat je de vervanging accepteert, en maak het token onbruikbaar na één succesvol gebruik.

Het e-mailkanaal maakt deel uit van het beveiligingsmodel. Het bezit van een accountnaam bewijst niets, en een resetstroom die onthult of een account bestaat, geeft een aanvaller een lijst om mee te werken.

Ongeldig wat het wachtwoord beschermde

Een wachtwoord wijzigen beëindigt niet automatisch de toegang die het gaf. Actieve VPN-sessies, onthouden apparaten en door de server uitgegeven tokens kunnen elk hun eigen ongeldigmakingsgedrag hebben. Beslis bewust welke daarvan moeten eindigen, en verifieer dat de implementatie dat doet, want een gebruiker die aanneemt dat een reset hem overal heeft uitgelogd, zit er vaak naast. Leg die beslissing vast samen met de stroom.

Voor beheerders: documenteer welke component het verzoek verifieert, welke de inloggegevens wijzigt en hoe gerelateerde sessies worden afgehandeld. Voor gebruikers: bescherm het legitieme herstelkanaal en behandel elk bericht dat een wachtwoord terugstuurt als verdacht.

De precieze beoordeling is kort: wat het bericht bewijst, wat onbekend blijft en of herstel de toegang vervangt door een gecontroleerd proces.