Lagret VPN-passord: hvem kan dekryptere det, og når

En VPN-klient som viser et kryptert passord i XML-en sin, har fortalt deg nesten ingenting. Cifferteksten sier bare at verdien ikke er lagret som ren tekst i den fremstillingen. Hvem som kan dekryptere den, med hvilken nøkkel og under hvilken brukerkontekst, er spørsmålene som avgjør om lagringen hjelper. Svar på dem før du kaller filen trygg eller utrygg.

Fastslå hvilket objekt som er lagret

Start med produktets dokumenterte lagringsmodell. En klient kan lagre et gjenopprettbart passord, et token eller en referanse til et påloggingslager, og hver av dem har ulik eksponering. Navnet på XML-elementet er ikke designet, og en streng som ser ut som base64 er heller ikke bevis på kryptering.

Spør leverandøren eller administratoren hvilken komponent som leser verdien ved tilkobling.

Finn deretter ut hvilket beskyttelses-API som brukes, hvis det er dokumentert. På Windows beskytter CryptProtectData data med en nøkkel som er utledet fra påloggingsopplysningene til brukeren som krypterer, og maskinvalget endrer hvem som kan dekryptere. Det er et konkret eksempel på hvorfor omfanget betyr noe. Det er ikke bevis for at en bestemt VPN-klient bruker det.

Skill en stjålet kopi fra bruk under kjøring

En klient som kobler til på nytt uten å spørre deg, trenger en støttet måte å hente påloggingsopplysningene på. Å beskytte en sikkerhetskopi fjerner ikke den muligheten. Ethvert program som kjører i riktig brukerkontekst, kan bruke samme vei, og derfor ligger endepunktet selv innenfor tillitsgrensen. Filrettigheter og prosessprivilegier snevrer inn grensen; de fjerner den ikke.

Det er denne forskjellen en påstand om en fil uten nettverk oftest tar feil av. Kryptering i ro kan stoppe noen som kopierer én fil uten kontoen. Den stopper ikke kode som kjører som kontoen.

Begge påstandene kan være sanne samtidig, og den andre er den som betyr noe under hendelseshåndtering.

Les tilgangskontrollene som faktisk gjelder

Sjekk ACL-en til filen og til mappen over den, ikke bare filmodusen. På Windows kan du sammenligne de effektive rettighetene til brukerprofilen med dem til klientens tjeneste eller planlagte oppgave. En hemmelighet som er beskyttet for én bruker, er ikke automatisk beskyttet mot en administrator, og den er heller ikke automatisk åpen for en.

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

Noter hvilken identitet som kjører klienten, fordi den identiteten er den som dekrypterer.

For en administrert flåte kan den relevante kontrollen være enhetsstyring i stedet for filen. Spør om påloggingsopplysningene holdes i depot, om de kan tilbakekalles eksternt, og hva prosessen er når en enhet blir borte.

Planlegg for eksponering i stedet for å teste dekryptering

Ikke kjør et ukjent uttrekksverktøy mot filen for å bevise et poeng. Det kan virke, det kan skade profilen, og uansett endrer det bevisene. Bruk det dokumenterte designet og en autorisert vurdering hvis verifisering virkelig er nødvendig.

Hvis eksponering er fastslått, roter påloggingsopplysningene hos eieren av identiteten.

Å slette den lagrede oppføringen er ikke tilbakekalling. Det kan hindre den klienten i å tilby verdien igjen, og det gjør ingenting med en kopi som allerede er tatt eller en økt som allerede er autorisert. Bytt ut påloggingsopplysningene, avslutt øktene eieren kan avslutte, og noter hva som ble rotert og når.

Spørsmålene for en leverandørgjennomgang

Spør hvilken hemmelighet som er lagret, hvilken komponent som bruker den, hvilken bruker- eller maskinnøkkel som beskytter den, hvilke tilgangskontroller som gjelder for normal bruk og sikkerhetskopier, og hvordan lagringspolicy og ugyldiggjøring eksternt håndteres. De fem svarene beskriver designet; XML-en gjør det ikke.

Ta vare på svarene sammen med utrullingsposten, slik at neste gjennomgang ikke gjentar øvelsen.

En lagret påloggingsopplysning er en byttehandel mellom bekvemmelighet og eksponering. Gjør byttet bevisst, og skriv ned hvem som godtok det.