La vostra contrasenya VPN és tan privada com el seu verificador

Recorreu quatre preguntes sobre qualsevol inici de sessió VPN: què protegeix la contrasenya en trànsit, quin component la rep, què en fa aquest component i què s’emmagatzema després. Cada resposta és un control diferent, i una resposta sòlida a una no diu res de les altres. L’error és tractar el xifratge del túnel com si cobrís les quatre. En cobreix la primera, i només la primera.

Pregunteu qui acaba la sessió, no si la sessió està xifrada.

Xifrada per a qui, exactament?

TLS protegeix la contrasenya entre el client i allò que acaba la connexió. Si aquest punt final és la passarel·la VPN, el codi d’autenticació de la passarel·la veu la contrasenya en text pla, la valida i la transmet o en transmet un valor derivat. Aquest és el disseny previst, no una fuita. Un observador de xarxa al camí no aprèn res d’útil, i el component que fa la verificació aprèn tot el que necessita.

La comunitat d’OpenVPN ho documenta explícitament: auth-user-pass-verify lliura les credencials enviades a un script o connector de verificació. És un lliurament intencionat entre components, i pertany al model de confiança com a part nomenada.

El verificador veu la contrasenya

Un cop un component rep una contrasenya per verificar-la, els seus controls d’accés, el registre i la qualitat del codi decideixen si el secret es queda contingut. Un script que escriu la credencial en un registre, o un connector que la guarda en memòria cau, crea una exposició molt més gran que la del protocol. L’accés depèn de l’arquitectura i dels rols, no del túnel, i per això el propietari del servei que controla el verificador pertany a l’avaluació.

Mètodes diferents exposen material diferent. L’autenticació per certificat demostra una clau privada sense enviar-la, i un flux de federació pot mantenir la contrasenya al proveïdor d’identitat mentre emet una asserció limitada a la VPN. Aquests dissenys estrenyen el cercle; cap d’ells elimina totes les parts de confiança.

Els hash emmagatzemats protegeixen una etapa diferent

L’orientació del NIST separa la transmissió protegida de l’emmagatzematge resistent del verificador. La sal i un esquema de hash amb cost aborden l’amenaça del verificador emmagatzemat, que és el que passa després dels fets si una base de dades es filtra. No fan res per a un component en temps d’execució que ha de rebre l’entrada per comparar-la. Llegir l’orientació com si prometés secret en temps d’execució és un error de categoria.

Així, un magatzem de contrasenyes ben hashejat i un script de verificació exposat poden conviure en un producte sense contradicció.

Triar un mètode que estrenyi el cercle

Si el requisit és que la passarel·la no rebi mai una contrasenya reutilitzable, trieu un mètode que realment ho garanteixi; canviar el xifratge de dades no crea aquesta propietat. Verificar el certificat del servidor VPN us diu a quin par heu arribat; no diu res sobre com aquest par tracta les credencials després. Manteniu la verificació del servidor, feu servir credencials diferents per servei i seguiu el flux d’identitat que l’organització admet.

Registreu la part que rep la contrasenya, la part que la valida i la forma en què es conserva. Aquestes tres respostes pertanyen al costat del perfil de connexió, perquè sobreviuen a qualsevol túnel concret.

La pregunta útil no és si la contrasenya està xifrada, sinó de qui s’amaga, quin component la rep i quina forma sobreviu després.