Sol·licitud MFA del VPN rebutjada: què ha de fer el client

Una sol·licitud MFA rebutjada sembla un problema de xarxa i no ho és. El servidor va demanar un segon factor, el factor va tornar negatiu o no va arribar mai, i la sessió es va rebutjar abans que existís cap túnel. El que passa després és una qüestió de comportament del client: mostrar la fallada i deixar que l’usuari comenci un intent net, o reintentar de maneres que generen més sol·licituds i acaben activant la protecció del compte. El segon camí és com un codi mal escrit es converteix en un compte bloquejat.

Comproveu quina sol·licitud ha fallat

Comenceu identificant quina sol·licitud ha fallat. Una notificació push, un codi TOTP, una asserció FIDO i un flux SAML fallen cadascun de manera diferent, i el client normalment sap quin ha demanat. Una denegació, un repte caducat i una fallada de lliurament que mai no va arribar al dispositiu acaben tots en el mateix error genèric, així que l’estat propi del client sovint és l’únic lloc on la diferència sobreviu.

Val la pena registrar aquest estat amb precisió. Registreu l’identificador del repte o la referència de la transacció, el tipus de factor, la marca temporal i el resultat, però mai el codi ni l’asserció. L’identificador del repte és el que permet a un administrador trobar l’esdeveniment al costat del proveïdor d’identitat; sense ell, la conversa amb el suport comença amb «en algun moment de l’última hora» i normalment s’hi acaba. Tracteu-lo com a metadades de diagnòstic, no com un secret.

Reintenteu un cop, deliberadament, amb un repte nou

Un reintent hauria de ser un intent nou amb un repte nou, no una repetició del vell. Quan el client reutilitza el repte anterior, el proveïdor d’identitat o el rebutja per caducat o, pitjor, accepta una aprovació pensada per a l’intent anterior. Demaneu un repte nou, mostreu-lo i deixeu que l’usuari actuï sobre el que és a la pantalla en aquest moment.

Dos intents amb una pausa curta entre ells és un valor per defecte raonable; un bucle il·limitat no ho és. Si el segon intent falla de la mateixa manera, atureu-vos i informeu en lloc de continuar.

Què no ha de fer el client

El client no ha de fer diverses coses que semblen útils i no ho són. No ha de continuar enviant notificacions push fins que algú toqui «aprova», perquè això ensenya els usuaris a aprovar sol·licituds que no han iniciat i és exactament el comportament en què es basen els kits de phishing. No ha de recórrer a un factor més feble perquè el fort ha fallat, i no ha de desactivar la comprovació d’identitat del servidor per passar per alt una queixa de certificat que va aparèixer alhora. Cadascuna d’aquestes tres dreceres converteix una fallada d’autenticació en un incident de seguretat.

Tampoc no ha d’empassar-se la fallada en silenci. Un client que tanca la connexió i mostra un indicador de càrrega deixa l’usuari sense cap idea de si ha de reintentar, esperar o trucar al suport. Mostreu la fallada amb el tipus de factor i un codi curt, manteniu el missatge sense secrets i feu l’acció de reintent explícita en lloc d’automàtica.

Si la sol·licitud no la va iniciar la persona davant del teclat, l’acció correcta és deixar-la rebutjada i informar-ne pel camí de suport verificat. Aprovar una sol·licitud per aturar el soroll és el mode de fallada, no la solució.

Què cal registrar per al suport

Per al suport, el registre útil és petit. L’hora aproximada amb la zona horària, el compte, el client i la versió, el tipus de factor i l’estat no secret de cada intent: sol·licitat, denegat, expirat, aprovat però rebutjat per la política.

Tingueu també a la vista els rellotges del client i del servidor. TOTP és una comprovació de finestra temporal, així que un dispositiu amb el rellotge desviat produeix codis que semblen vàlids i fallen cada vegada, i un client que informa d’un codi no vàlid sense assenyalar el desviament envia la gent a restablir credencials que mai no estaven malament. Un usuari a qui l’inici de sessió falla repetidament hauria de comprovar la versió compatible del client, l’estat d’enregistrament i el flux de recuperació documentat abans de generar més sol·licituds.

El camí de recuperació mereix la mateixa cura que el d’inici de sessió. Un flux per a dispositius perduts existeix precisament perquè un rebuig no es converteixi en permís per saltar-se l’autenticació, i un client hauria d’enllaçar el procés documentat de l’organització en lloc d’improvisar-ne un.

La regla contra la qual cal construir és que el rebuig és un resultat, no un obstacle. Informeu-ne una vegada, amb claredat, amb prou context per actuar-hi, i deixeu que el següent intent sigui nou. Les indicacions de CISA sobre MFA resistent al phishing expliquen per què el patró de demanar fins a l’aprovació és perillós d’entrada, i és la referència que val la pena citar quan algú proposa un bucle de reintents. Tot el que el client afegeixi després d’un rebuig hauria de fer la decisió següent més fàcil per a una persona, no treure-li la decisió.