Зачувана VPN лозинка: кој може да ја дешифрира и кога

VPN клиент што прикажува шифрирана лозинка во својот XML не ви кажал речиси ништо. Шифрираниот текст одговара само дека вредноста не е зачувана како обичен текст во тој приказ. Кој може да ја дешифрира, со каков клуч и во каков кориснички контекст, се прашањата што одлучуваат дали складирањето помага. Одговорете на нив пред да ја наречете датотеката безбедна или небезбедна.

Утврдете кој објект се чува

Започнете со документираниот модел на складирање на производот. Клиентот може да чува лозинка што може да се врати, токен или упатување до складиште на акредитиви, и секое од нив има различно изложување. Името на XML елементот не е дизајнот, а ниту низата што изгледа како base64 не е доказ за шифрирање.

Прашајте го добавувачот или администраторот кој компонент ја чита вредноста при поврзување.

Потоа утврдете го API за заштита ако е документиран. Во Windows, CryptProtectData штити податоци со клуч изведен од акредитивите за најава на корисникот што шифрира, а неговата опција за машински опсег менува кој може да дешифрира. Ова е конкретен пример зошто опсегот е важен. Тоа не е доказ дека некој конкретен VPN клиент го користи тој API.

Одвојте украдена копија од употреба при извршување

Клиентот што се поврзува повторно без да ве праша има потреба од поддржан начин да ги врати акредитивите. Заштитата на резервна копија не ја отстранува таа можност. Секоја програма што работи во правилниот кориснички контекст може да го користи истиот пат, затоа самата крајна точка е во границите на доверба. Дозволите за датотеки и привилегиите на процесите ја стеснуваат таа граница; не ја отстрануваат.

Токму оваа разлика тврдењето за офлајн датотека обично погрешно ја разбира. Шифрирањето во мирување може да го запре оној што копира една датотека без сметката. Не запре код што работи како сметката.

Двете тврдења можат да бидат точни истовремено, а второто е она што е важно при одговор на инцидент.

Прочитајте ја контролата на пристап што навистина се применува

Проверете го ACL на датотеката и директориумот над неа, не само режимот на датотеката. Во Windows, споредете ги ефективните дозволи на корисничкиот профил со оние на услугата или закажаната задача на клиентот. Тајната заштитена за еден корисник не е автоматски заштитена од администратор, ниту е автоматски изложена на него.

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

Забележете кој идентитет го извршува клиентот, бидејќи тој идентитет е субјектот на дешифрирањето.

За управуван парк, релевантната контрола може да биде управување со уреди наместо датотеката. Прашајте дали акредитивите се депонираат, дали можат да се отповикаат од далечина и каков е процесот кога уред ќе се изгуби.

Планирајте изложување наместо да го тестирате дешифрирањето

Не извршувајте непозната алатка за извлекување врз датотеката за да докажете нешто. Може да работи, може да го оштети профилот и во секој случај ги менува доказите. Користете го документираниот дизајн и овластена проценка ако проверката е навистина потребна.

Ако изложувањето е утврдено, заменете ги акредитивите кај сопственикот на идентитетот.

Бришењето на зачуваниот запис не е отповикување. Тоа може да го спречи тој клиент повторно да ја понуди вредноста и не прави ништо за веќе земена копија или веќе овластена сесија. Заменете ги акредитивите, завршете ги сесиите што сопственикот може да ги заврши и запишете што е заменето и кога.

Прашањата за преглед на добавувачот

Прашајте која тајна се чува, кој компонент ја користи, кој кориснички или машински клуч ја штити, кои контроли на пристап важат за нормална употреба и резервни копии и како се постапува со политиката за чување и далечинското поништување. Тие пет одговори го опишуваат дизајнот; XML не.

Чувајте ги одговорите со записот за распоредување за следниот прегледувач да не ја повторува вежбата.

Зачуваните акредитиви се размена помеѓу удобност и изложување. Направете ја размената намерно и запишете кој ја прифатил.