Dues sol·licituds de contrasenya no són MFA: què verifica un inici de sessió VPN

La pàgina d’inici de sessió demana una contrasenya i després un segon secret, i de seguida la implantació es descriu com a multifactor. De vegades ho és. Sovint és un sol factor recollit dues vegades, perquè tots dos valors són coneixement que la mateixa persona ha escrit de la mateixa memòria o de la mateixa nota. Un xifratge de túnel fort no ho canvia, i la paraula «segur» al nom del producte tampoc.

Separar l’afirmació del mecanisme només requereix una pregunta: què demostra cada pas, i a qui?

Un factor és una prova, no un camp

L’autenticació multifactor significa que es verifica més d’un tipus diferent de prova per al mateix compte: alguna cosa que l’usuari sap, alguna cosa que té, alguna cosa que és. Dos camps que recullen tots dos una cadena recordada són un sol tipus de prova demanat dues vegades. Pot ser un control útil, ja que dos secrets independents són més difícils d’endevinar que un, però no és el que descriu el terme i no s’hauria de comptar com a tal en una avaluació de riscos.

El costat de la verificació importa tant com el costat de la recollida. Un codi generat en un dispositiu només demostra el control d’aquest dispositiu si el servidor el comprova contra un secret lligat a aquest compte i rebutja les repeticions. Un codi compartit que funciona per a tothom, un codi sense límit d’intents o una sol·licitud aprovada en un dispositiu que mai no mostra què s’està aprovant són més febles del que suggereix l’etiqueta.

Així que quan algú pregunti si la VPN té MFA, pregunteu què demostra el segon pas i com el servidor el lliga. Si la resposta és «una segona contrasenya del mateix directori», teniu un factor i una conversa sobre polítiques, no un segon factor.

El cas del certificat s’ha de llegir, no suposar

Un certificat de client més una contrasenya sembla dos factors, i pot ser-ho: el certificat es guarda en un magatzem o en un testimoni, i la contrasenya es recorda. També pot ser-ne un, si el fitxer del certificat és sense protecció al mateix directori de perfil que la contrasenya desada, o si el certificat es va emetre per a un dispositiu que diverses persones comparteixen sense responsabilitat individual.

La qüestió a resoldre és qui o què identifica el certificat. Un certificat de dispositiu demostra que hi ha una màquina gestionada present. Un certificat d’usuari demostra una identitat. Si la implantació emet un certificat per portàtil i després tracta la seva presència com a prova de la persona, el segon factor s’ha convertit en silenci en una propietat del maquinari que hereta qualsevol que tingui el portàtil.

Res d’això fa que els certificats siguin una mala idea. Fa que la distinció entre garantia del dispositiu i garantia de l’usuari es mereixi posar per escrit, perquè les dues responen a preguntes diferents i un full de càlcul de compliment que les compta com una sola exagerarà el que està protegit.

La confiança en la passarel·la i la confiança en l’usuari són problemes separats

Un segon factor no fa segur escriure credencials en un punt final que no heu verificat. El client ha de reconèixer la passarel·la prevista, i és per a això que hi ha el certificat del servidor i la configuració de confiança del client. El phishing funciona traslladant l’inici de sessió a un servidor que controla l’atacant, i un codi d’un sol ús correcte introduït allà simplement es retransmet al servei real en temps real.

Per això l’elecció del mètode canvia el resultat més que la redacció de la sol·licitud. Els codis escrits per una persona poden ser retransmesos per qualsevol que pugui mostrar una pàgina convincent, mentre que els mètodes criptogràfics que lliguen l’autenticació a l’origen i a la sessió concrets resisteixen aquesta retransmissió per disseny. Quin dels dos teniu és una propietat del mètode, no del nombre de passos del diàleg.

Seguiu el flux d’inscripció i de client que admet el proveïdor en lloc de cargolar una sol·licitud addicional en un camp de contrasenya. Un segon pas fet a casa sol quedar en algun punt intermedi, afegint fricció sense el lligam que dona sentit al factor.

La recuperació és la segona porta d’entrada

Tot inici de sessió fort té un camí de tornada quan es perd l’autenticador, i aquest camí és on el disseny sol ser més feble. Si un agent de suport pot restablir el segon factor després d’una trucada a un número registrat, la ruta més barata per a l’atacant és el servei d’ajuda, no la pàgina d’inici de sessió.

Pregunteu com funciona la substitució, qui l’aprova i quines proves exigeixen. Després comproveu que el material de recuperació, com els codis de reserva, es guarda per separat de la credencial principal, de manera que una sola bretxa no lliuri totes dues. La guia sobre identitat digital del NIST tracta el lligam del verificador i el cicle de vida de l’autenticador com a part del requisit, no com una reflexió operativa.

Què cal escriure a l’avaluació

Descriviu els factors per tipus, nombreu què demostra cadascun i exposeu com està lligat al compte. Anoteu si el mètode resisteix la retransmissió i descriviu el camí de recuperació amb la mateixa cura que l’inici de sessió.

Després digueu clarament si la implantació és multifactor segons aquesta definició. «Dues contrasenyes i un certificat de màquina» és una frase honesta, i diu a un lector molt més que una casella que marca sí.