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

En VPN-klient som viser et kryptert passord i XML-en sin, har ikke fortalt deg stort. Chifferteksten svarer bare at verdien ikke lagres som klartekst i den representasjonen. Hvem som kan dekryptere den, med hvilken nøkkel og i 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 lagres

Start med produktets dokumenterte lagringsmodell. En klient kan lagre et gjenopprettbart passord, et token eller en referanse til et legitimasjonslager, og hver har ulik eksponering. XML-elementnavnet 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.

Identifiser deretter beskyttelses-API-et hvis det er dokumentert. I Windows beskytter CryptProtectData data med en nøkkel avledet fra påloggingsinformasjonen til brukeren som krypterer, og maskinomfang-alternativet 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 API-et.

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 å gjenopprette legitimasjonen på. Beskyttelse av 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 innsnevrer den grensen; de fjerner den ikke.

Det er denne forskjellen en påstand om en offline-fil vanligvis tar feil av. Kryptering i hvile kan stoppe noen som kopierer én fil uten kontoen. Det 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

Kontroller filens ACL og mappen over, ikke bare filmodusen. I Windows, sammenlign de effektive tillatelsene 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 eksponert for en.

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

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

For en administrert flåte kan den relevante kontrollen være enhetsadministrasjon i stedet for filen. Spør om legitimasjonen deponeres, om den kan tilbakekalles eksternt, og hva prosessen er når en enhet mistes.

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 legitimasjonen hos identitetseieren.

Sletting av 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 legitimasjonen, 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 lagres, 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 fjernannullering håndteres. De fem svarene beskriver designet; XML-en gjør det ikke.

Oppbevar svarene sammen med utrullingsregistreringen slik at neste gjennomgang ikke gjentar øvelsen.

En lagret legitimasjon er en byttehandel mellom bekvemmelighet og eksponering. Gjør byttehandelen bevisst, og skriv ned hvem som godtok den.