Lagra VPN-passord: kven kan dekryptere det, og når

Ein VPN-klient som viser eit kryptert passord i XML-en sin, har fortalt deg nesten ingenting. Cifferteksten svarar berre at verdien ikkje er lagra som rein tekst i den framstillinga. Kven som kan dekryptere han, med kva nøkkel og under kva brukarkontekst, er spørsmåla som avgjer om lagringa hjelper. Svar på dei før du kallar fila trygg eller utrygg.

Fastset kva objekt som er lagra

Start med den dokumenterte lagringsmodellen til produktet. Ein klient kan lagre eit gjenopprettbart passord, eit token eller ei vise til eit innloggingslager, og kvart av dei har ulik eksponering. Namnet på XML-elementet er ikkje designet, og ein streng som ser ut som base64 er heller ikkje prov på kryptering.

Spør leverandøren eller administratoren kva komponent som les verdien ved tilkopling.

Finn så ut kva vernande API som blir brukt, dersom det er dokumentert. På Windows vernar CryptProtectData data med ein nøkkel som er utleia frå påloggingsopplysningane til brukaren som krypterer, og maskinvalet endrar kven som kan dekryptere. Det er eit konkret døme på kvifor omfanget tel. Det er ikkje prov på at ein bestemt VPN-klient brukar han.

Skil ein stolen kopi frå bruk under køyring

Ein klient som koplar til på nytt utan å spørje deg, treng ein støtta måte å hente innloggingsdata på. Å verne ein reservekopi fjernar ikkje den moglegheita. Eit kvar program som køyrer i rett brukarkontekst, kan bruke same vegen, og difor ligg endepunktet sjølv innanfor tillitsgrensa. Filrettar og prosessprivilegium snevrar grensa inn; dei fjernar henne ikkje.

Det er denne skilnaden ein påstand om ei fil utan nettverk oftast tek feil av. Kryptering i ro kan stoppe nokon som kopierer éi fil utan kontoen. Ho stoppar ikkje kode som køyrer som kontoen.

Begge påstandane kan vere sanne samstundes, og den andre er den som tel under hendingshandtering.

Les tilgangskontrollane som faktisk gjeld

Sjekk ACL-en til fila og til mappa over henne, ikkje berre filmodusen. På Windows kan du samanlikne dei effektive rettane til brukarprofilen med dei til tenesta eller den planlagde oppgåva til klienten. Ein løyndom som er verna for éin brukar, er ikkje automatisk verna mot ein administrator, og han er heller ikkje automatisk open for ein.

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

Skriv ned kva identitet som køyrer klienten, for den identiteten er den som dekrypterer.

For ein administrert flåte kan den relevante kontrollen vere einingsstyring i staden for fila. Spør om innloggingsdata blir haldne i depot, om dei kan trekkjast attende på avstand, og kva prosessen er når ei eining blir borte.

Planlegg for eksponering i staden for å teste dekryptering

Ikkje køyr eit ukjent uttrekkingsverktøy mot fila for å bevisa eit poeng. Det kan verke, det kan skade profilen, og kvar veg endrar det bevisa. Bruk det dokumenterte designet og ei godkjend vurdering dersom stadfesting verkeleg er naudsynt.

Dersom eksponering er stadfesta, roter innloggingsdataa hos eigaren av identiteten.

Å slette den lagra oppføringa er ikkje tilbakekalling. Det kan hindre den klienten i å tilby verdien på nytt, og det gjer ingenting med ein kopi som alt er teken eller ei økt som alt er godkjend. Byt ut innloggingsdataa, avslutt øktene eigaren kan avslutte, og skriv ned kva som vart rotert og når.

Spørsmåla for ein leverandørgjennomgang

Spør kva løyndom som er lagra, kva komponent som brukar han, kva brukar- eller maskinnøkkel som vernar han, kva tilgangskontrollar som gjeld for vanleg bruk og reservekopiar, og korleis lagringspolicy og ugyldiggjering på avstand blir handtert. Dei fem svara skildrar designet; XML-en gjer det ikkje.

Ta vare på svara saman med utrullingsoppføringa, slik at neste gjennomgangar ikkje gjer om øvinga.

Eit lagra innloggingsdata er eit bytte mellom komfort og eksponering. Gjer byttet med vilje, og skriv ned kven som godtok det.