Openbaar VPN-wachtwoord: waarom het niet je e-mailwachtwoord mag zijn

Profielen in openbare VPN-mappen noemen een server, een gebruikersnaam en een wachtwoord die duizenden andere mensen ook hebben, en de verleiding is om iets gedenkwaardigs te typen. Juist dat instinct is het probleem: de waarde is geen persoonlijk geheim, en alles waarvoor je hem hergebruikt, wordt ook openbaar. Behandel de gepubliceerde login als een gedeelde sleutel voor een openbare dienst, en elk account dat jou identificeert als een volledig andere categorie. De scheiding is eenvoudig te handhaven tot de dag dat het ertoe doet.

Wat de inloggegevens werkelijk zijn

Een login die in een openbare VPN-map wordt gepubliceerd, is een toegangsregeling tussen de exploitant en iedereen die de pagina leest. Hij kan een gedeeld serviceaccount in plaats van een persoon identificeren, en de exploitant kan de verbinding bij de gateway observeren.

Dat laatste punt verdient nadruk: wie een tunnel beëindigt, ziet het verkeer dat erin en eruit gaat, en houdt het wachtwoord dat hem heeft geopend. Hergebruik van een waarde voor een mailaccount vertelt de exploitant iets over een account dat hij nooit had mogen kunnen raden. Een gedeeld wachtwoord is in geen enkele betekenisvolle zin een geheim, omdat veel mensen het hebben. De categorieën zijn verschillend: een openbaar toegangsgeheim, een privé-accountwachtwoord, een cliëntcertificaat en een peersleutel, elk beantwoordt een andere vraag.

Hergebruik is een bekende waarde, geen zwakke

Richtlijnen voor wachtwoordsterkte richten zich meestal op lengte en uniciteit, en uniciteit is precies wat hergebruik vernietigt. Een lang wachtwoord dat op twee plaatsen wordt gebruikt, is op beide plaatsen een bekende waarde zodra een van de twee lekt.

Credential stuffing is afhankelijk van die overlap, en openbare mappen maken de eerste helft van het paar gratis voor iedereen. Voor elke dienst een aparte waarde genereren haalt die hefboom weg zonder iets gedenkwaardigers te vereisen. Lengte compenseert nooit een waarde die al op een openbare pagina is gedrukt.

Als het wachtwoord al is hergebruikt

Wijzig het niet-gerelateerde account via het geverifieerde herstelproces, en beoordeel daarna de actieve sessies en herstelinstellingen, want een reset die een oude sessie in leven laat, heeft het werk niet afgemaakt. Stuur het wachtwoord niet naar VPN-ondersteuning om de fout te demonstreren. Waar meerledige authenticatie beschikbaar is, schakel die in, want die overleeft een gelekt wachtwoord.

Roteer de VPN-inloggegevens via welk proces de exploitant ook documenteert, en merk op dat dit een aparte actie is van het wijzigen van je eigen account. Houd de twee wijzigingen in hetzelfde ticket, zodat niemand aanneemt dat de ene de andere dekte.

Als een privé-cliëntsleutel is blootgesteld in plaats van een wachtwoord, is intrekking het middel. Het wijzigen van een e-mailwachtwoord verwijdert geen gekopieerde sleutel.

Controleer het type inloggegevens voordat je roteert

Stel vast wat het veld werkelijk verwacht voordat je iets genereert. Een portaalruimtecode, een peersleutel en een wachtwoord zijn niet uitwisselbaar, en het verkeerde roteren laat de blootstelling staan.

python3 -c 'import secrets; print(secrets.token_urlsafe(24))'
gpg --gen-random --armor 2 32
pass generate work/mail 24

Bewaar gegenereerde waarden in een wachtwoordbeheerder in plaats van een notitie, zodat afzonderlijke vermeldingen bruikbaar blijven. Bevestig daarna dat de nieuwe waarde werkt voordat je de oude weggooit, en houd beide gebeurtenissen in hetzelfde ticket.

Sluit af met het opschonen van opgeslagen inloggegevens op elke gedeelde installatie die de oude login gebruikte. Een inloggegeven dat van de server is verwijderd, is nog steeds een lek als een apparaat opnieuw verbinding blijft maken met een gecachte kopie.