Primer el mètode EAP: quin hash de contrasenya pot fer servir una VPN
La VPN verifica el secret, no el hash web. Llegeix el mètode i després comprova què guarda el magatzem abans de prometre que les mateixes contrasenyes continuaran funcionant.
Molts equips tenen un inici de sessió web que funciona i una VPN que rebutja cada contrasenya de la mateixa taula. L'aplicació web compara un hash que ha calculat ella mateixa, mentre que el túnel demana al client que demostri la possessió d'un secret d'una manera que el servidor ha de poder comprovar. Són requisits diferents sobre el material emmagatzemat. És en l'escletxa entre tots dos on s'encallen la majoria d'aquests projectes.
Primer el mètode, després l'esquema
Anota quina prova exigeix el mètode triat abans de mirar cap esquema. Un mètode de repte-resposta necessita material a partir del qual el servidor pugui calcular la resposta esperada, cosa que a la pràctica vol dir la contrasenya o una forma derivada compatible. Un mètode que porta la contrasenya dins d'un túnel protegit necessita la contrasenya mateixa al verificador. Llegeix la documentació del mètode pel que fa al requisit del verificador i no a la configuració del client, perquè els requisits del client solen ser la part fàcil.
Un hash amb sal produït per un marc web modern no ofereix cap de les dues. Verifica una comparació concreta i no es pot revertir cap al secret del qual va sortir.
El repte-resposta no pot fer servir un hash amb sal
MSCHAPv2 és un intercanvi de repte-resposta, així que el servidor no rep mai la contrasenya i no pot comparar cap cadena emmagatzemada. Ha de derivar la resposta esperada a partir del material que ja té, i per això les formes emmagatzemades compatibles són tan estretes. Un valor bcrypt o Argon2 amb una sal per usuari és d'un sol sentit d'una manera que descarta l'intercanvi del tot. La taula de sota parteix de la forma d'emmagatzematge i no del nom del mètode, perquè la forma d'emmagatzematge és el que decideix la resposta.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
La documentació del connector SQL per a strongSwan defineix un esquema propi per a la configuració i les credencials, i el projecte encara marca aquest connector com a experimental. Res no s'hi adapta a la taula d'usuaris d'una aplicació ni endevina quin esquema de hash va produir un valor emmagatzemat. Les opcions realistes són, doncs, migrar a un magatzem que la passarel·la pugui fer servir, o un servei d'autenticació davant del magatzem existent que pugui fer l'intercanvi. Qualsevol altra cosa és un connector amb una suposició amagada a dins.
RADIUS mou la feina, no el requisit
Delegar EAP a un servidor RADIUS canvia on es fa la verificació i normalment millora el rastre d'auditoria. No recupera una contrasenya d'un hash d'un sol sentit, així que el servei d'autenticació encara necessita material compatible amb el mètode que acaba. Els equips ho descobreixen després de construir el camí RADIUS i de trobar la mateixa paret a l'altre extrem.
On el servidor RADIUS pot llegir un directori amb una credencial compatible, el disseny funciona i la passarel·la VPN es manté simple. On no pot, la resposta honesta és un canvi d'alta i no un altre connector. L'aprovisionament i la revocació pertanyen a qui posseeix la identitat, així que una taula copiada sense un procés de sincronització suportat és un segon cicle de vida de credencials i no un inici de sessió únic. Es desvia el primer cop que algú restableix una contrasenya en un sol lloc, i la desviació és silenciosa fins que un compte que existeix en tots dos sistemes es comporta de manera diferent a cadascun.
Limita el compte que llegeix el directori a aquesta lectura i mantén-lo separat del compte que la passarel·la fa servir per a la seva pròpia configuració. Un compte administratiu compartit converteix un disseny de només lectura en un radi d'impacte molt més ampli.
On ha de viure el compte
Un cop resolta la qüestió del material, queden dues arquitectures. La passarel·la pot tenir un petit magatzem de credencials que només ella llegeix, o pot delegar en un servei d'autenticació que es posa davant del directori corporatiu.
La primera és més fàcil de raonar i pitjor per a l'usuari, que acaba amb una segona contrasenya per mantenir. La segona conserva una identitat i afegeix una dependència d'un servei que ara ha d'estar disponible abans que ningú es pugui connectar. Cap de les dues no és incorrecta, però l'elecció s'hauria d'enregistrar al costat de la configuració de la passarel·la, perquè si no el proper enginyer assumirà que s'ha triat l'altra. Trieu el que trieu, les dues ordres de sota són les que mostren l'estat actual abans de canviar-lo.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsL'autenticació del compte tampoc no resol l'autorització. La pertinença a grups, l'estat del dispositiu i el permís de xarxa encara necessiten un mapatge explícit un cop l'usuari ha demostrat la identitat requerida. Una connexió que s'autentica perfectament i no autoritza res és un resultat de política, no un error del mètode.