Jou VPN-wagwoord is net so privaat soos sy verifieerder

Werk deur vier vrae oor enige VPN-aanmelding: wat die wagwoord tydens versending beskerm, watter komponent dit ontvang, wat daardie komponent daarmee doen, en wat daarna gestoor word. Elke antwoord is 'n ander beheer, en 'n sterk antwoord op een sê niks oor die ander nie. Die fout is om tonnelversleuteling te behandel asof dit al vier dek. Dit dek die eerste, en net die eerste.

Vra wie die sessie beëindig eerder as of die sessie versleutel is.

Versleutel vir wie, presies?

TLS beskerm die wagwoord tussen die kliënt en wat ook al die verbinding beëindig. As daardie eindpunt die VPN-gateway is, sien die gateway se verifikasiekode die gewone wagwoord, valideer dit, en gee dit of 'n afgeleide waarde verder. Dit is die bedoelde ontwerp, nie 'n lek nie. 'n Netwerkwaarnemer op die pad leer niks nuttigs, en die komponent wat die verifikasie doen, leer alles wat dit nodig het.

Die gemeenskap van OpenVPN dokumenteer dit uitdruklik: auth-user-pass-verify oorhandig die ingediende geloofsbriewe aan 'n verifikasieskrip of inprop. Dit is 'n doelbewuste oorhandiging tussen komponente, en dit hoort as 'n genoemde party in die vertrouensmodel.

Die verifieerder sien die wagwoord

Sodra 'n komponent 'n wagwoord ontvang om dit te verifieer, bepaal daardie komponent se toegangsbeheer, logboeke en kodegehalte of die geheim ingehoue bly. 'n Skrip wat die geloofsbriewe in 'n logboek skryf, of 'n inprop wat dit kas, skep 'n veel groter blootstelling as wat die protokol gedoen het. Toegang hang van argitektuur en rolle af eerder as van die tonnel, en daarom hoort 'n dienseienaar wat die verifieerder beheer in die assessering.

Verskillende metodes stel verskillende materiaal bloot. Sertifikaatverifikasie bewys 'n private sleutel sonder om dit te stuur, en 'n federasievloei kan die wagwoord by die identiteitsverskaffer hou terwyl dit 'n beperkte bewering aan die VPN uitreik. Daardie ontwerpe vernou die kring; nie een van hulle skakel elke vertroude party uit nie.

Gestoorde hashes beskerm 'n ander stadium

NIST se leiding skei beskermde versending van weerbare verifieerderberging. Sout en 'n gekoste hashskema spreek die gestoorde-verifieerder-bedreiging aan, wat is wat agterna gebeur as 'n databasis uitlek. Hulle doen niks aan 'n looptydkomponent wat die inset moet ontvang om dit te vergelyk nie. Om die leiding te lees asof dit looptydgeheimhouding belowe, is 'n kategorie-fout.

'n Goed gehashte wagwoordstoor en 'n blootgestelde verifikasieskrip kan dus sonder teenspraak in een produk saam bestaan.

Kies 'n metode wat die kring vernou

As die vereiste is dat die gateway nooit 'n herbruikbare wagwoord ontvang nie, kies 'n metode wat dit werklik waarborg; om 'n data-syfer te verander skep nie daardie eienskap nie. Om die VPN-bediener se sertifikaat te verifieer sê vir jou watter eweknie jy bereik het; dit sê niks oor hoe daardie eweknie daarna geloofsbriewe hanteer nie. Hou bedienerverifikasie, gebruik afsonderlike geloofsbriewe per diens, en volg die organisasie se ondersteunde identiteitsvloei.

Teken die party aan wat die wagwoord ontvang, die party wat dit valideer en die vorm waarin dit behou word. Daardie drie antwoorde hoort langs die verbindingsprofiel, want hulle oorleef enige bepaalde tonnel.

Die nuttige vraag is nie of die wagwoord versleutel is nie, maar vir wie dit weggesteek word, watter komponent dit ontvang en watter vorm daarna oorleef.