Fjalëkalimi juaj i VPN është vetëm aq privat sa verifikuesi i tij

Kaloni nëpër katër pyetje për çdo hyrje VPN: çfarë e mbron fjalëkalimin gjatë tranzitit, cili komponent e merr atë, çfarë bën ai komponent me të, dhe çfarë ruhet më pas. Çdo përgjigje është një kontroll tjetër, dhe një përgjigje e fortë për njërën nuk thotë asgjë për të tjerat. Gabimi është ta trajtosh kriptimin e tunelit sikur mbulon të katërtat. Ai mbulon të parën, dhe vetëm të parën.

Pyet kush e përfundon sesionin, jo nëse sesioni është i kriptuar.

I kriptuar për kë, saktësisht?

TLS e mbron fjalëkalimin mes klientit dhe asaj që e përfundon lidhjen. Nëse ai pikë fundor është porta VPN, kodi i vërtetimit të portës e sheh fjalëkalimin në tekst të thjeshtë, e vërteton dhe e përçon më tej atë ose një vlerë të prejardhur. Ky është dizajni i synuar, jo një rrjedhje. Një vëzhgues i rrjetit në rrugë nuk mëson asgjë të dobishme, dhe komponenti që kryen verifikimin mëson gjithçka që i nevojitet.

Komuniteti i OpenVPN e dokumenton këtë në mënyrë eksplicite: auth-user-pass-verify ia dorëzon kredencialet e paraqitura një skripti ose shtojce verifikimi. Është një dorëzim i qëllimshëm mes komponentëve, dhe i përket modelit të besimit si palë e emërtuar.

Verifikuesi e sheh fjalëkalimin

Pasi një komponent merr një fjalëkalim për ta verifikuar, kontrollet e tij të aksesit, regjistrimi dhe cilësia e kodit vendosin nëse sekreti mbetet i mbyllur. Një skript që shkruan kredencialet në një regjistër, ose një shtojcë që i ruan në memorie, krijon një ekspozim shumë më të madh sesa krijoi protokolli. Aksesi varet nga arkitektura dhe rolet, jo nga tuneli, prandaj pronari i shërbimit që kontrollon verifikuesin bën pjesë në vlerësim.

Metoda të ndryshme ekspozojnë material të ndryshëm. Vërtetimi me certifikatë provon një çelës privat pa e dërguar atë, dhe një rrjedhë federimi mund ta mbajë fjalëkalimin te ofruesi i identitetit duke lëshuar një pohim të kufizuar për VPN-në. Këto dizajne e ngushtojnë rrethin; asnjë prej tyre nuk eliminon çdo palë të besuar.

Hash-et e ruajtura mbrojnë një fazë tjetër

Udhëzimi i NIST ndan transmetimin e mbrojtur nga ruajtja rezistente e verifikuesit. Kripa dhe një skemë hash me kosto adresojnë kërcënimin e verifikuesit të ruajtur, që është ajo që ndodh pas faktit nëse një bazë të dhënash rrjedh. Ato nuk bëjnë asgjë për një komponent në kohë ekzekutimi që duhet ta marrë inputin për ta krahasuar. Të lexosh udhëzimin sikur premton fshehtësi në kohë ekzekutimi është gabim kategorie.

Prandaj një depo fjalëkalimesh e hash-uar mirë dhe një skript verifikimi i ekspozuar mund të bashkëjetojnë në një produkt pa kundërshtim.

Zgjedhja e një metode që e ngushton rrethin

Nëse kërkesa është që porta të mos marrë kurrë një fjalëkalim të ripërdorshëm, zgjidh një metodë që vërtet e garanton këtë; ndryshimi i një shifre të dhënash nuk e krijon atë veti. Verifikimi i certifikatës së serverit VPN të tregon se cilin palë ke arritur; nuk thotë asgjë për mënyrën se si ai palë i trajton kredencialet më pas. Mbaje verifikimin e serverit, përdor kredenciale të veçanta për çdo shërbim dhe ndiq rrjedhën e identitetit që mbështet organizata.

Regjistro palën që merr fjalëkalimin, palën që e vërteton dhe formën në të cilën mbahet. Këto tre përgjigje i përkasin profilit të lidhjes, sepse jetojnë më gjatë se çdo tunel i veçantë.

Pyetja e dobishme nuk është nëse fjalëkalimi është i kriptuar, por nga kush fshihet, cili komponent e merr dhe çfarë forme mbijeton më pas.