VPNko MFA eskaera baztertua: zer egin behar du bezeroak

Baztertutako MFA eskaera sare-arazo baten itxura du eta ez da. Zerbitzariak bigarren faktore bat eskatu zuen, faktorea negatiboan itzuli zen edo ez zen inoiz iritsi, eta saioa ukatu egin zen tunelik existitu aurretik. Ondoren gertatzen dena bezeroaren jokabidearen kontua da: hutsegitea erakutsi eta erabiltzaileari saiakera garbi bat hasteko aukera eman, edo modu ezberdinetan berriz saiatu, eskaera gehiago sortu eta kontuaren babesa aktibatzeraino. Bigarren bidea da kode gaizki idatzi bat nola bihurtzen den blokeatutako kontu.

Egiaztatu zein eskaerak huts egin duen

Hasi zein eskaerak huts egin duen identifikatzen. Push jakinarazpen batek, TOTP kode batek, FIDO adierazpen batek eta SAML fluxu batek modu desberdinean huts egiten dute, eta bezeroak normalean badaki zein eskatu zuen. Ukatze batek, iraungitako erronka batek eta gailura inoiz iritsi ez zen entrega-hutsegite batek errore generiko berberean amaitzen dute, beraz bezeroaren beraren egoera izaten da askotan aldea bizirik irauten duen toki bakarra.

Egoera hori zehaztasunez erregistratzea merezi du. Erregistratu erronkaren identifikatzailea edo transakzioaren erreferentzia, faktore mota, denbora-marka eta emaitza, baina inoiz ez kodea edo adierazpena. Erronkaren identifikatzailea da administratzaile bati identitate-hornitzailearen aldean gertaera aurkitzeko aukera ematen diona; hura gabe, laguntza-elkarrizketa «azken ordubetean noizbait» esaldiarekin hasten da eta normalean han amaitzen da. Tratatu diagnostiko-metadatu gisa, ez sekretu gisa.

Saiatu berriz behin, nahita, erronka berri batekin

Berriz saiatzeak saiakera berria izan behar du, erronka berri batekin, ez zahararen errepikapena. Bezeroak aurreko erronka berrerabiltzen duenean, identitate-hornitzaileak zaharkitu gisa baztertzen du edo, are okerrago, aurreko saiakerarako zen onespena onartzen du. Eskatu erronka berri bat, erakutsi eta utzi erabiltzaileari une honetan pantailan dagoenaren gainean jarduten.

Bi saiakera tarte labur batekin zentzuzko lehenetsia da; begizta mugagabea ez. Bigarren saiakera modu berean huts egiten badu, gelditu eta jakinarazi, jarraitu beharrean.

Zer ez duen bezeroak egin behar

Bezeroak ez du hainbat gauza egin behar, lagungarri diruditenak eta ez direnak. Ez du push jakinarazpenak bidaltzen jarraitu behar norbaitek «onartu» ukitu arte, horrek erabiltzaileak berak hasi ez zituen eskaerak onartzen irakasten dizkie eta hori da phishing-kit-ek hain zuzen ere behar duten jokabidea. Ez du faktore ahulago batera jo behar indartsuak huts egin duelako, eta ez du zerbitzariaren identitate-egiaztapena desaktibatu behar aldi berean agertu den ziurtagiri-erreklamazio bat gainditzeko. Hiru lasterbide horietako bakoitzak autentifikazio-hutsegite bat segurtasun-intzidente bihurtzen du.

Eta ez du hutsegitea isilpean irentsi behar. Konexioa ixten duen eta spinner bat erakusten duen bezero batek erabiltzailea erabaki ezinik uzten du: ea berriz saiatu, itxaron edo laguntza-talderiari deitu. Erakutsi hutsegitea faktore motarekin eta kode labur batekin, eduki mezua sekreturik gabe, eta egin berriz saiatzeko ekintza esplizitua, ez automatikoa.

Eskaera teklatu aurrean dagoen pertsonak hasi ez badu, ekintza zuzena baztertuta uztea eta egiaztatutako laguntza-bidetik jakinaraztea da. Zarata gelditzeko eskaera bat onartzea porrot-eredua da, ez konponbidea.

Zer erregistratu laguntzarako

Laguntzarako, erregistro erabilgarria txikia da. Gutxi gorabeherako ordua, ordu-eremuarekin, kontua, bezeroa eta bertsioa, faktore mota, eta saiakera bakoitzaren egoera ez-sekretua: eskatua, ukatua, iraungia, onartua baina politikak baztertua.

Eduki begi-bistan bezeroaren eta zerbitzariaren erlojuak ere. TOTP denbora-leihoaren egiaztapena da, beraz erlojua desbideratu zaion gailu batek baliozko itxurako kodeak sortzen ditu eta beti huts egiten du, eta desbideratzea aipatu gabe kode baliogabea jakinarazten duen bezeroak inoiz oker egon ez diren kredentzialak berrezartzera bidaltzen ditu pertsonak. Saio-hasierak behin eta berriz huts egiten dion erabiltzaileak bezeroaren bertsio onartua, erregistratze-egoera eta dokumentatutako berreskuratze-fluxua egiaztatu beharko lituzke eskaera gehiago sortu aurretik.

Berreskuratze-bideak saio-hasierak adina arreta merezi du. Galdutako gailu baterako fluxua zehazki existitzen da ukatze bat ez dadin autentifikazioa saihesteko baimen bihur, eta bezeroak erakundearen dokumentatutako prozesuari esteka eman beharko lioke, bera asmatu ordez.

Eraiki beharreko araua hau da: ukatzea emaitza da, ez oztopoa. Jakinarazi behin, argi, jarduteko testuinguru nahikorekin, eta utzi hurrengo saiakerari berria izaten. CISAk phishingari aurre egiten dion MFA gaiari buruz emandako gidalerroek azaltzen dute zergatik den «onarpena arte galdetu» eredua arriskutsua hasieratik, eta hura da aipatzeko balio duen erreferentzia norbaitek berriz saiatzeko begizta bat proposatzen duenean. Bezeroak ukatze baten ondoren gehitzen duen guztiak hurrengo erabakia pertsonarentzat errazagoa egin beharko luke, ez erabakia kendu.