Jūsu VPN parole ir tik tik privāta, cik privāts ir tās pārbaudītājs

Izskatiet četrus jautājumus par jebkuru VPN pieteikšanos: kas aizsargā paroli pārraides laikā, kurš komponents to saņem, ko šis komponents ar to dara un kas tiek saglabāts pēc tam. Katra atbilde ir cita kontrole, un spēcīga atbilde uz vienu neko nepasaka par pārējām. Kļūda ir uzskatīt tuneļa šifrēšanu par tādu, kas aptver visus četrus. Tā aptver pirmo, un tikai pirmo.

Jautājiet, kas beidz sesiju, nevis vai sesija ir šifrēta.

Šifrēta kam, precīzāk?

TLS aizsargā paroli starp klientu un to, kas beidz savienojumu. Ja šis galapunkts ir VPN vārteja, vārtejas autentifikācijas kods redz paroli atklātā tekstā, pārbauda to un nodod tālāk to vai atvasinātu vērtību. Tas ir paredzētais dizains, nevis noplūde. Tīkla novērotājs ceļā neuzzina neko noderīgu, un pārbaudi veicošais komponents uzzina visu, kas tam nepieciešams.

OpenVPN kopiena to skaidri dokumentē: auth-user-pass-verify nodod iesniegtos akreditācijas datus pārbaudes skriptam vai spraudnim. Tā ir apzināta nodošana starp komponentiem, un tā kā nosaukta puse ietilpst uzticības modelī.

Pārbaudītājs redz paroli

Kad komponents ir saņēmis paroli, lai to pārbaudītu, tā piekļuves kontroles, reģistrēšana un koda kvalitāte nosaka, vai noslēpums paliek iekšpusē. Skripts, kas ieraksta akreditācijas datus žurnālā, vai spraudnis, kas tos kešatmiņā, rada daudz lielāku atklāšanu nekā protokols. Piekļuve ir atkarīga no arhitektūras un lomām, nevis no tuneļa, tāpēc pakalpojuma īpašnieks, kurš kontrolē pārbaudītāju, ietilpst novērtējumā.

Dažādas metodes atklāj dažādu materiālu. Autentifikācija ar sertifikātu pierāda privāto atslēgu, to nenosūtot, un federācijas plūsma var paturēt paroli identitātes nodrošinātājā, vienlaikus izsniedzot VPN ierobežotu apgalvojumu. Šie dizaini sašaurina loku; neviens no tiem neizslēdz visas uzticamās puses.

Saglabātie jaucējkodi aizsargā citu posmu

NIST vadlīnijas atdala aizsargātu pārraidi no noturīgas pārbaudītāja glabāšanas. Sāls un dārga jaucējshēma risina saglabātā pārbaudītāja draudus, proti, to, kas notiek pēc tam, ja datubāze noplūst. Tās neko nedara izpildlaika komponentam, kuram ir jāsaņem ievade, lai to salīdzinātu. Vadlīnijas lasīt tā, it kā tās solītu izpildlaika slepenību, ir kategorijas kļūda.

Tāpēc labi jaucēta paroļu glabātuve un atklāts pārbaudes skripts var bez pretrunām pastāvēt vienā produktā.

Metodes izvēle, kas sašaurina loku

Ja prasība ir, ka vārteja nekad nesaņem atkārtoti izmantojamu paroli, izvēlieties metodi, kas to patiešām garantē; datu šifra maiņa šo īpašību nerada. VPN servera sertifikāta pārbaude jums pasaka, kuru partneri sasniedzāt; tā neko nepasaka par to, kā šis partneris pēc tam rīkojas ar akreditācijas datiem. Saglabājiet servera pārbaudi, izmantojiet atsevišķus datus katram pakalpojumam un ievērojiet organizācijas atbalstīto identitātes plūsmu.

Pierakstiet pusi, kas saņem paroli, pusi, kas to pārbauda, un formu, kādā tā tiek glabāta. Šīs trīs atbildes pieder pie savienojuma profila, jo tās pārdzīvo jebkuru konkrētu tuneli.

Noderīgais jautājums nav, vai parole ir šifrēta, bet no kā tā tiek slēpta, kurš komponents to saņem un kāda forma paliek pēc tam.