VPN-salasanasi on yhtä yksityinen kuin sen tarkistaja

Käy läpi neljä kysymystä mistä tahansa VPN-kirjautumisesta: mikä suojaa salasanaa siirron aikana, mikä komponentti vastaanottaa sen, mitä kyseinen komponentti tekee sillä ja mitä tallennetaan jälkeenpäin. Jokainen vastaus on eri kontrolli, ja vahva vastaus yhteen ei kerro muista mitään. Virhe on kohdella tunnelin salausta ikään kuin se kattaisi kaikki neljä. Se kattaa ensimmäisen ja vain ensimmäisen.

Kysy, kuka lopettaa istunnon, älä sitä, onko istunto salattu.

Salattu keneltä, tarkalleen?

TLS suojaa salasanaa asiakkaan ja yhteyden lopettavan osapuolen välillä. Jos tuo päätepiste on VPN-yhdyskäytävä, sen todennuskoodi näkee salasanan selkokielisenä, validoi sen ja välittää eteenpäin joko sen tai johdetun arvon. Se on tarkoitettu rakenne, ei vuoto. Verkon tarkkailija polulla ei opi mitään hyödyllistä, ja tarkistuksen tekevä komponentti oppii kaiken tarvitsemansa.

OpenVPN-yhteisö dokumentoi tämän nimenomaisesti: auth-user-pass-verify luovuttaa toimitetut tunnistetiedot tarkistusskriptille tai liitännäiselle. Se on tarkoituksellinen luovutus komponenttien välillä, ja se kuuluu luottamusmalliin nimettynä osapuolena.

Tarkistaja näkee salasanan

Kun komponentti vastaanottaa salasanan tarkistaakseen sen, sen käyttöoikeudet, lokitus ja koodin laatu ratkaisevat, pysyykö salaisuus suljettuna. Skripti, joka kirjoittaa tunnistetiedot lokiin, tai liitännäinen, joka välimuistittaa ne, synnyttää paljon suuremman altistuksen kuin protokolla. Pääsy riippuu arkkitehtuurista ja rooleista, ei tunnelista, minkä vuoksi tarkistajaa hallitseva palvelun omistaja kuuluu arviointiin.

Erilaiset menetelmät paljastavat erilaista aineistoa. Varmenteeseen perustuva todennus todistaa yksityisen avaimen lähettämättä sitä, ja federaatiovirta voi pitää salasanan identiteetintarjoajalla ja myöntää VPN:lle rajattu väite. Nämä rakenteet kaventavat piiriä, mutta mikään niistä ei poista kaikkia luotettuja osapuolia.

Tallennetut tiivisteet suojaavat eri vaihetta

NISTin ohjeet erottavat suojatun siirron tarkistajan kestävästä tallennuksesta. Suolaus ja kustannuksellinen tiivistyskaava käsittelevät tallennetun tarkistajan uhkaa, joka toteutuu jälkikäteen, jos tietokanta vuotaa. Ne eivät tee mitään ajonaikaiselle komponentille, jonka on vastaanotettava syöte vertailua varten. Ohjeiden lukeminen ikään kuin ne lupaisivat ajonaikaisen salaisuuden on kategoriavirhe.

Hyvin tiivistetty salasanavarasto ja julkinen tarkistusskripti voivat siis olla samassa tuotteessa ristiriidatta.

Valitaan menetelmä, joka kaventaa piiriä

Jos vaatimus on, ettei yhdyskäytävä koskaan saa uudelleenkäytettävää salasanaa, valitse menetelmä, joka todella takaa sen; datasalauksen vaihtaminen ei luo tätä ominaisuutta. VPN-palvelimen varmenteen tarkistaminen kertoo, mihin vastapuoleen pääsit; se ei kerro mitään siitä, miten tämä osapuoli sen jälkeen käsittelee tunnistetietoja. Pidä palvelintarkistus, käytä erillisiä tunnistetietoja kullekin palvelulle ja noudata organisaation tukemaa identiteettivirtaa.

Kirjaa osapuoli, joka vastaanottaa salasanan, osapuoli, joka validoi sen, ja muoto, jossa se säilytetään. Nämä kolme vastausta kuuluvat yhteyden profiilin viereen, koska ne elävät pidempään kuin mikään yksittäinen tunneli.

Hyödyllinen kysymys ei ole, onko salasana salattu, vaan keneltä se on piilotettu, mikä komponentti sen vastaanottaa ja mikä muoto säilyy jälkeenpäin.