Sparat VPN-lösenord: vem kan dekryptera det och när

En VPN-klient som visar ett krypterat lösenord i sin XML har inte berättat nästan något för dig. Chiffertexten svarar bara på att värdet inte lagras som klartext i den representationen. Vem som kan dekryptera det, med vilken nyckel och i vilken användarkontext är de frågor som avgör om lagringen hjälper. Besvara dem innan du kallar filen säker eller osäker.

Fastställ vilket objekt som lagras

Börja med produktens dokumenterade lagringsmodell. En klient kan lagra ett återställbart lösenord, en token eller en referens till ett förvar för inloggningsuppgifter, och var och en har olika exponering. XML-elementets namn är inte designen, och en sträng som ser ut som base64 är inte heller bevis på kryptering.

Fråga leverantören eller administratören vilken komponent som läser värdet vid anslutning.

Identifiera sedan skydds-API:t om det är dokumenterat. I Windows skyddar CryptProtectData data med en nyckel som härleds från den krypterande användarens inloggningsuppgifter, och maskininställningen ändrar vem som kan dekryptera. Det är ett konkret exempel på varför omfattningen spelar roll. Det är inte bevis för att någon särskild VPN-klient använder det API:t.

Skilj en stulen kopia från användning vid körning

En klient som återansluter utan att fråga dig behöver ett stött sätt att återställa inloggningsuppgiften. Att skydda en säkerhetskopia tar inte bort den förmågan. Varje program som körs i rätt användarkontext kan använda samma väg, och därför ligger själva slutpunkten innanför förtroendegränsen. Filrättigheter och processprivilegier begränsar den gränsen; de tar inte bort den.

Det är denna skillnad som ett påstående om en offlinefil oftast missar. Kryptering i vila kan stoppa någon som kopierar en fil utan kontot. Det stoppar inte kod som körs som kontot.

Båda påståendena kan vara sanna samtidigt, och det andra är det som spelar roll vid incidenthantering.

Läs åtkomstkontrollerna som faktiskt gäller

Kontrollera filens ACL och katalogen ovanför den, inte bara filmoden. I Windows kan du jämföra användarprofilens effektiva behörigheter med dem för klientens tjänst eller schemalagda aktivitet. En hemlighet som skyddas för en användare är inte automatiskt skyddad mot en administratör och inte heller automatiskt utsatt för en.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Notera vilken identitet som kör klienten, eftersom den identiteten är dekrypteringens subjekt.

För en hanterad flotta kan den relevanta kontrollen vara enhetshantering i stället för filen. Fråga om uppgiften förvaras i deposition, om den kan återkallas på distans och hur processen ser ut när en enhet försvinner.

Planera för exponering i stället för att testa dekryptering

Kör inte ett okänt extraheringsverktyg mot filen för att bevisa en poäng. Det kan fungera, det kan skada profilen och det ändrar bevisningen oavsett. Använd den dokumenterade designen och en auktoriserad bedömning om verifiering verkligen krävs.

Om exponering är fastställd, rotera uppgiften hos identitetens ägare.

Att radera den sparade posten är inte återkallande. Det kan hindra den klienten från att erbjuda värdet igen och gör ingenting åt en kopia som redan tagits eller en session som redan auktoriserats. Byt ut uppgiften, avsluta de sessioner som ägaren kan avsluta och notera vad som roterades och när.

Frågorna för en leverantörsgranskning

Fråga vilken hemlighet som lagras, vilken komponent som använder den, vilken användar- eller maskinnyckel som skyddar den, vilka åtkomstkontroller som gäller för normal användning och säkerhetskopior, och hur sparandepolicy och fjärrinvalidering hanteras. De fem svaren beskriver designen; XML:en gör det inte.

Behåll svaren tillsammans med driftsättningsposten så att nästa granskare inte upprepar övningen.

En sparad uppgift är ett byte mellan bekvämlighet och exponering. Gör bytet medvetet och skriv ned vem som godtog det.