Offentligt VPN-lösenord: varför det inte får vara ditt e-postlösenord

Profiler i offentliga VPN-kataloger listar en server, ett användarnamn och ett lösenord som tusentals andra också har, och frestelsen är att skriva något minnesvärt. Just den instinkten är problemet: värdet är inte en personlig hemlighet, och allt du återanvänder det till blir också offentligt. Behandla den publicerade inloggningen som en delad nyckel till en offentlig tjänst, och varje konto som identifierar dig som en helt annan kategori. Åtskillnaden är enkel att upprätthålla ända till den dag den spelar roll.

Vad inloggningsuppgifterna egentligen är

En inloggning som publiceras i en offentlig VPN-katalog är en åtkomstöverenskommelse mellan operatören och alla som läser sidan. Den kan identifiera ett delat tjänstekonto i stället för en person, och operatören kan observera anslutningen vid gatewayen.

Den sista punkten förtjänar betoning: den som avslutar en tunnel ser trafiken som går in och ut ur den, och har lösenordet som öppnade den. Återanvändning av ett värde för ett e-postkonto berättar för operatören något om ett konto de aldrig borde ha kunnat gissa. Ett delat lösenord är inte en hemlighet i någon meningsfull mening, eftersom många människor har det. Kategorierna är olika: en offentlig åtkomsthemlighet, ett privat kontolösenord, ett klientcertifikat och en peer-nyckel, var och en svarar på en annan fråga.

Återanvändning är ett känt värde, inte ett svagt

Råd om lösenordsstyrka fokuserar vanligtvis på längd och unikhet, och unikhet är precis vad återanvändning förstör. Ett långt lösenord som används på två ställen är ett känt värde på båda när ett av ställena läcker.

Credential stuffing beror på den överlappningen, och offentliga kataloger gör den första halvan av paret gratis för alla. Att generera ett eget värde per tjänst tar bort den hävstången utan att kräva något mer minnesvärt. Längd kompenserar aldrig för ett värde som redan är tryckt på en offentlig sida.

Om lösenordet redan har återanvänts

Byt det orelaterade kontot via dess verifierade återställningsprocess, granska sedan dess aktiva sessioner och återställningsinställningar, eftersom en återställning som lämnar en gammal session vid liv inte har slutfört jobbet. Skicka inte lösenordet till VPN-supporten för att demonstrera misstaget. Där multifaktorautentisering är tillgänglig, aktivera den, eftersom den överlever ett läckt lösenord.

Rotera VPN-inloggningsuppgifterna genom vilken process operatören än dokumenterar, och notera att detta är en separat åtgärd från att ändra ditt eget konto. Håll de två ändringarna i samma ärende så att ingen antar att den ena täckte den andra.

Om en privat klientnyckel exponerades i stället för ett lösenord, är återkallelse botemedlet. Att ändra ett e-postlösenord tar inte bort en kopierad nyckel.

Kontrollera inloggningsuppgifternas typ innan du roterar

Identifiera vad fältet faktiskt förväntar sig innan du genererar något. En portalkod, en peer-nyckel och ett lösenord är inte utbytbara, och rotation av fel typ lämnar exponeringen kvar.

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

Förvara genererade värden i en lösenordshanterare i stället för en anteckning, så att olika poster förblir användbara. Bekräfta sedan att det nya värdet fungerar innan du kastar det gamla, och håll båda händelserna i samma ärende.

Avsluta med att rensa sparade inloggningsuppgifter på varje delad installation som använde den gamla inloggningen. En inloggningsuppgift som tagits bort från servern är fortfarande en läcka om en enhet fortsätter att återansluta med en cachad kopia.