Spremljena VPN lozinka: tko je može dešifrirati i kada
Šifrirani tekst u klijentskoj datoteci ne dokazuje gotovo ništa. Utvrdite vlasnika ključa, upotrebu tijekom izvođenja i kontrole pristupa prije nego prosudite pohranu.
VPN klijent koji prikazuje šifriranu lozinku u svom XML-u nije vam rekao gotovo ništa. Šifrirani tekst odgovara samo na to da vrijednost nije pohranjena kao obični tekst u tom prikazu. Tko je može dešifrirati, kojim ključem i u kojem korisničkom kontekstu, pitanja su koja odlučuju pomaže li pohrana. Odgovorite na njih prije nego datoteku nazovete sigurnom ili nesigurnom.
Utvrdite koji se objekt pohranjuje
Počnite s dokumentiranim modelom pohrane proizvoda. Klijent može pohraniti lozinku koja se može vratiti, token ili uputu na spremište vjerodajnica, a svaki od njih ima drukčiju izloženost. Naziv XML elementa nije dizajn, a ni niz koji izgleda kao base64 nije dokaz šifriranja.
Pitajte dobavljača ili administratora koja komponenta čita vrijednost u trenutku povezivanja.
Zatim utvrdite API za zaštitu ako je dokumentiran. Na Windowsu CryptProtectData štiti podatke ključem izvedenim iz podataka za prijavu korisnika koji šifrira, a njegova opcija na razini stroja mijenja tko može dešifrirati. To je konkretan primjer zašto je opseg važan. To nije dokaz da neki određeni VPN klijent rabi taj API.
Odvojite ukradenu kopiju od upotrebe tijekom izvođenja
Klijent koji se ponovno povezuje bez pitanja treba podržan način da vrati vjerodajnicu. Zaštita sigurnosne kopije ne uklanja tu mogućnost. Svaki program koji radi u ispravnom korisničkom kontekstu može rabiti isti put, zato je samo krajnje računalo unutar granice povjerenja. Dopuštenja datoteka i privilegije procesa sužavaju tu granicu; ne uklanjaju je.
To je razlika koju tvrdnja o izvanmrežnoj datoteci obično pogrešno shvaća. Šifriranje u mirovanju može zaustaviti nekoga tko kopira jednu datoteku bez računa. Ne zaustavlja kod koji radi kao račun.
Obje tvrdnje mogu biti točne istodobno, a druga je ona koja je važna tijekom odgovora na incident.
Pročitajte kontrole pristupa koje se stvarno primjenjuju
Provjerite ACL datoteke i direktorij iznad nje, ne samo način rada datoteke. Na Windowsu usporedite efektivna dopuštenja korisničkog profila s onima klijentske usluge ili planiranog zadatka. Tajna zaštićena za jednog korisnika nije automatski zaštićena od administratora, a nije mu ni automatski izložena.
icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv
Zabilježite koji identitet pokreće klijent, jer je taj identitet subjekt dešifriranja.
Za upravljani park relevantna kontrola može biti upravljanje uređajima, a ne datoteka. Pitajte je li vjerodajnica deponirana, može li se opozvati na daljinu i kakav je postupak kada se uređaj izgubi.
Planirajte izloženost umjesto testiranja dešifriranja
Ne pokrećite nepoznat alat za izdvajanje na datoteci da biste nešto dokazali. Može uspjeti, može oštetiti profil i u svakom slučaju mijenja dokaze. Rabite dokumentirani dizajn i ovlaštenu procjenu ako je provjera doista potrebna.
Ako je izloženost utvrđena, zamijenite vjerodajnicu kod vlasnika identiteta.
Brisanje spremljene stavke nije opoziv. Ono može spriječiti taj klijent da ponovno ponudi vrijednost i ne čini ništa u vezi s već uzetom kopijom ili već ovlaštenom sesijom. Zamijenite vjerodajnicu, završite sesije koje vlasnik može završiti i zabilježite što je zamijenjeno i kada.
Pitanja za pregled dobavljača
Pitajte koja se tajna pohranjuje, koja je komponenta rabi, koji korisnički ili strojni ključ je štiti, koje se kontrole pristupa primjenjuju na uobičajenu upotrebu i sigurnosne kopije te kako se upravlja pravilom spremanja i daljinskim poništenjem. Tih pet odgovora opisuje dizajn; XML ne.
Držite odgovore uz zapis o implementaciji da sljedeći pregledatelj ne ponavlja vježbu.
Spremljena vjerodajnica je razmjena između praktičnosti i izloženosti. Napravite tu razmjenu namjerno i zapišite tko ju je prihvatio.