A hitelesítési UX újragondolása
Javítsunk a hitelesítési UX folyamatainkon és hárítsuk el az akadályokat a belépni és regisztrálni szándékozó felhasználók előtt!
Senki sem ébred fel reggel abban a reményben, hogy aznap végre azonosítani tudja a zebrákat, a kereszteződési lámpákat és a tűzcsapokat. Mégis minden nap különböző akadályok leküzdésére kényszerítjük a felhasználókat, amikor regisztrálni és bejelentkezni szeretnének egy-egy oldalra.
Tegyük könnyebbé a dolgukat! Javítsunk a bonyodalmas hitelesítési folyamatainkon és hárítsuk el az akadályokat a felhasználók előtt!
Mit tehetünk a hitelesítési UX javítása érdekében?
Senki sem ébred fel reggel abban a reményben, hogy aznap végre azonosítani tudja a zebrákat, a kereszteződési lámpákat és a tűzcsapokat. Mégis minden nap különböző akadályok leküzdésére kényszerítjük a felhasználókat, hogy regisztráljanak és bejelentkezzenek, hogy elég összetett jelszót állítsanak be vagy állítsanak vissza, hogy megtalálják a módját annak, hogy visszaállítsák a hozzáférést a zárolt fiókokhoz és a kijelentkezett munkamenetekhez.
Mivel a CAPTCHA-k már nem működnek, olyan feladatokat kell megoldanunk, amelyek a gépek számára is elég nehezek. Ez persze nem felhasználóbarát, de legalább biztonságos.
Természetesen a biztonság számít, mégis túl gyakran kerül a használhatóság útjába. Ahogy Jared Spool mondta egyszer: „Ha egy termék nem használható, akkor nem is biztonságos”. Ez pontosan az a helyzet, amikor az emberek elkezdenek privát e-mail fiókokat használni, és a jelszavakat cetlikre írják, mert különben elfelejtik őket.
Mit tehetünk tehát a hitelesítési UX javítása érdekében?
1. Ne tiltsuk le a jelszavak másolás-beillesztését
Ésszerűnek tűnik, hogy a jelszavak beviteléhez a másolás-beillesztést blokkoljuk, hogy elkerüljük a brute-force támadásokat. Mégis, amikor ezt tesszük, akkor azokat a felhasználókat is blokkoljuk, akik jelszókezelőkből és szöveges dokumentumokból másolják be a jelszavaikat. Ennek eredményeképpen többször is be kell gépelniük összetett, hosszú, rejtélyes szövegrészleteiket – és ez többnyire egy olyan kaland, amibe nincs kedvük belevágni az átlag felhasználóknak.
Miért is? Mert lassú, bosszantó és frusztráló. Az Authentication UX Anti-Patterns című előadásában Kelly Robinson elmagyarázza, hogy ez egy gyakori anti-pattern, amely gyakran sokkal több frusztrációt okoz, mint amennyit orvosol, és ezért jobb, ha elkerüljük.
Megkönnyíthetjük az emberek számára a biztonságos jelszavak használatát, ahelyett, hogy helyben kitalálnának egyet. Kétszer is ellenőrizze, hogy a jelszómezők tartalmazzák-e az autocomplete=”new-password” attribútumot, hogy a böngészők erős, automatikusan generált jelszót kérhessenek. És ami a legjobb: a jelszókezelővel nem rendelkező felhasználóknak nem kell saját jelszóval előállniuk – mert ez amúgyis általában a katasztrófa receptje.
2. Ne hagyatkozz egyedül a jelszavakra
A jelszavak problémásak. Az Egyesült Államokban például a felhasználók mindössze 34%-a használ jelszókezelőt, mindenki más a jó öreg memóriájára, a cetlikre és az asztalon lévő szöveges fájlokra hagyatkozik.
A jó jelszavakat nehéz megjegyezni. Emiatt a felhasználók gyakran választanak helyette könnyen kitalálható jelszavakat, például háziállataik és szeretteik nevét, születési dátumukat és esküvőjük dátumát vagy ezeknek valamilyen kombinációját. Ez persze korántsem biztonságos.
A jelszavak helyzete nem tűnik túl biztatónak. Ha valamilyen módon elkerülhetnénk a jelszavak használatát, akkor biztosan elkerülnénk a használatukat.
A jellemző az, hogy gyakran elfelejtjük a jelszavainkat, néha hetente 4-5 alkalommal is helyreállítjuk a jelszavakat. Így nem csoda, hogy sokan még mindig ugyanazt a jelszót használjuk több fiókban is, gyakran a kényelmet részesítve előnyben az adatbiztonsággal szemben. Valójában az, hogy a felhasználóknak megengedjük, hogy maguk válasszák meg jelszavaikat, az a későbbi problémák receptje. Hogy ezt orvosoljuk, mi lenne, ha eltanácsolnánk a felhasználókat a jelszavaktól?
Bármilyen 2-faktoros hitelesítés jobb, mint a jelszavak, és ideális esetben használhatnánk egy olyan sütit, amelyet a felhasználók választhatnak, hogy elkerüljék a gyakori bejelentkezéseket. Az adatérzékeny webhelyek minden látogatás után automatikusan ki akarják jelentkezni a felhasználókat (pl. online banki szolgáltatások), de az egyszerűbb webhelyek talán jobban teszik, ha elkerülik az agresszív kiléptetéseket, és lehetővé teszik a felhasználók számára, hogy 30 napig vagy még tovább maradjanak bejelentkezve.
3. Szigorú jelszókövetelmények elhagyása
Mivel a felhasználók nagyon jók a jelszószabályok kiforgatásában (csak azért, hogy a feladat elvégzése után nem sokkal elfelejtsék azokat), mi lenne, ha teljesen megváltoztatnánk a stratégiánkat? Mi lenne, ha támogatnánk a hosszú és összetett jelszavakat az összes különleges karakterrel egyedi elválasztójelekkel, de a szabályokat viszonylag barátságosan tartanánk?
A Mailchimp nagyon egyszerűen kezeli a jelszószabályokat. A legtöbb jelszókezelő – böngészőbe épített és külső – könnyedén megfelelne ezeknek.
Mindez persze biztosan a biztonság rovására menne. Ezért a felhasználók adatainak védelme érdekében a new-password segítségével a regisztráció során biztonságos jelszavakat kérünk létrehozni, és agresszívan ösztönözzük a felhasználókat a 2FA beállítására, például 30%-os kedvezményt biztosítunk az első hónapban a 2FA bekapcsolásáért.
Az egyetlen dolog, amire szükség lenne, hogy a fiókot mobiltelefonnal vagy a Google Authenticatorral összekapcsolják, beírjanak egy ellenőrző kódot, vagy Touch-ID-vel ellenőrizzék, és ennyi. Így elkerüljük a végtelen és drága jelszó-visszaállításokat, amelyek gyakran okoznak lemondást és frusztrációt.
4. A közösségi bejelentkezés nem mindenkinek való
Minél érzékenyebbek a tárolt adatok, annál nagyobb figyelmet várnak el a felhasználók a felülettől a biztonságra. A használhatósági ülések arra utalnak, hogy a bejelentkezési akadályokat látszólag elfogadják, amíg „ésszerűnek” tekintik őket. De ami nekünk, tervezőknek ésszerű, az nem feltétlenül az, ami az ügyfeleinknek ésszerű. Kiemelhetjük a korábban használt opciót, hogy megkönnyítsük az ügyfelek számára, hogy kiderítsék, mivel jelentkeztek be legutóbb. A közösségi bejelentkezés (Facebook, Google fiókok) jó példa erre. Egyes felhasználók szeretik, mert olyan gyors, mások azonban az adatvédelmi aggályok miatt általában ellenzik. Ráadásul a GDPR, CCPA és hasonló jogszabályoknak is meg kell felelnünk, ha használjuk.
Ne feledjük azt sem, hogy egyes felhasználók elfelejtik, hogy legutóbb mivel regisztráltak, ezért érdemes jelezni a korábbi választásukat az előző bejelentkezésük alapján. Lényegében a közösségi bejelentkezés remek lehetőség azoknak, akik egyszerűen csak el akarják intézni a dolgaikat, de nem lehet az egyetlen lehetőség, amit biztosítunk.
5. A biztonsági kérdéseket helyettesítsük 2FA-val
Egy ideális világban a biztonsági kérdéseknek – mint amilyeneket egy bank kérdez tőlünk telefonon a személyazonosságunk igazolására – segíteniük kellene a csalások megelőzésében. Lényegében ez egy második védelmi réteg, de mind a használhatóság, mind a biztonság szempontjából feltűnően rosszul teljesít. A kedvenc háziállatokra, leánykori nevekre és az első iskolára vonatkozó kérdésekre könnyen rájöhetünk, ha elég sokáig görgetjük a Facebook-adatfolyamot.
A PayPal még mindig biztonsági kérdéseket használ a felhasználó személyazonosságának ellenőrzésére. Ez nem különösebben felhasználóbarát vagy biztonságos.
Ennek tudatában a felhasználók néha ugyanazzal a válasszal válaszolnak ezekre a kérdésekre (pl. a születésnapjuk vagy a születési helyük), sőt néha ugyanazt a jelszót használják, amelyet eredetileg is megadtak. Ez nem igazán segít senkinek. A mágikus linkek és a push-értesítések sokkal biztonságosabbak, és egyáltalán nem kell megjegyezni a válaszokat.
6. A felhasználóknak lehetőségekre van szükségük a hozzáférés helyreállításához
Semmi sem lehet frusztrálóbb annál, mint amikor éppen a rossz pillanatban zárják ki az embert. Tervezőként tudatos kiutakat kövezhetünk ki a felületeinkben a hozzáférés helyreállításának több alternatív módjával (hozzáférés helyreállítása stack), és végleg elkerülhetjük ezeket a problémákat.
Gyakran gondolunk a jelszó-visszaállításra, hogy segítsük a felhasználókat a hozzáférés helyreállításában, de talán a hozzáférés helyreállításáról való gondolkodás jobb perspektíva a probléma megközelítéséhez. Ha egy felhasználó egy adott pillanatban nem tud bejelentkezni, nem igazán érdekli, hogy egy vadonatúj biztonságos jelszót határozzon meg, vagy olyan e-mailt vagy speciális karaktereket találjon, amelyeket korábban még nem használt. Egyszerűen csak be kell jelentkezniük. Nekünk pedig segítenünk kell nekik ebben.
A mágikus linkek fantasztikusak a hozzáférés helyreállításához, de néha előfordulhat, hogy a felhasználók nem férnek hozzá az e-mailjükhöz.
A hozzáférés helyreállításának összes technikája közül a mágikus linkek biztosan a hozzáférés helyreállításának részét fogják képezni. Úgy tűnik, a felhasználók értékelik, hogy milyen gyorsan vissza tudnak jutni, ha egyszer kizárták őket. Általában hibátlanul működnek, kivéve, ha az e-mail nem érkezik meg, vagy a fiók egy elavult e-mailhez kapcsolódik, vagy az e-mail postafiók vagy a telefon nem elérhető.
A mágikus linkek használatához a felhasználóknak kontextust kell váltaniuk, a böngészőből a levelezőprogramba, majd vissza a böngészőbe. Lehet, hogy gyorsabb lett volna, ha a felhasználókat ehelyett arra kérik, hogy a telefonjukon írjanak be egy kódot a belépéshez. Akár így, akár úgy, a lezárások elkerülése érdekében többféle lehetőséget biztosítunk a gyors helyreállítás garantálása érdekében, és a lehetőségek keveréke működik a legjobban:
Segítenünk kell a felhasználóknak a hozzáférés gyors helyreállításában. Ahhoz, hogy rugalmasak legyünk, használhatunk egy teljes hozzáférés-helyreállítási stacket.
Küldjünk egy mágikus linket a bejelentkezéshez e-mailben.
Ne követeljük meg a felhasználóktól, hogy újra beírják a jelszót, vagy új jelszót állítsanak be. Előfordulhat, hogy a felhasználók nem férnek hozzá az e-mailhez, vagy azt feltörhetik.
Küldjön egy mágikus linket a bejelentkezéshez egy másodlagos e-mailben.
Sajnos a másodlagos e-mail gyakran elavult, vagy a felhasználó esetleg nem fér hozzá.
Küldjön SMS-verifikációs URL-t/kódot egy mobiltelefonra.
Ez a lehetőség nem működik azoknál a felhasználóknál, akik új telefont vásároltak, vagy nem férnek hozzá a SIM-kártyájukhoz (pl. külföldi utazás esetén).
Push-értesítés küldése OTP/2FA-n keresztül.
Ez az opció nem működik azoknál a felhasználóknál, akik új telefont vásároltak, és még nem állították be az OTP/2FA-t, vagy nem férnek hozzá a régi telefonjukhoz.
Biometrikus hitelesítés dedikált alkalmazáson keresztül/Yubikey.
Ez a lehetőség nem működik azoknál a felhasználóknál, akik még nem rendelkeznek OTP/2FA beállítással, vagy új telefont/Yubikey-t vásároltak.
Gépelje be a biztonsági mentés helyreállítási kódjait.
Nem minden felhasználónak lesznek a közelben biztonsági mentési helyreállítási kódok, de ha vannak, akkor ezeknek mindig felül kell írniuk a fióklezárást. Néha a biztonsági mentési kódokat postai úton küldik, de ezek elveszhetnek/lophatják.
Telefonos ellenőrzés.
A felhasználókat fel lehetne hívni az (új) telefonjukon, és néhány kérdésre kellene válaszolniuk, hogy igazolják a személyazonosságukat. Ideális esetben olyasvalamit, amit tudnak (pl. legutóbbi tranzakciók), olyasvalamit, amivel rendelkeznek (pl. hitelkártya) és olyasvalamit, ami ők maguk (pl. arcfelismerés videóhíváson keresztül).
Ügyfélszolgálati megkeresés.
Ideális esetben a felhasználók visszaállíthatnák a hozzáférést egy ügynökkel való beszélgetéssel élő chat-en, WhatsApp/Telegramon, videóhíváson vagy e-mailen keresztül (ami általában a leglassabb).
Nem jó ötlet véletlenszerűen generált jelszavakat küldeni e-mailben, és új jelszó beállítását követelni, amikor a felhasználónak végre sikerül bejelentkeznie. Ez nem biztonságos, és mindig gondot okoz. Ehelyett, még egyszer, ösztönözze a felhasználókat a 2FA beállítására, hogy a telefonjukra telepített alkalmazásból vagy SMS-ben (ami azonban kevésbé biztonságos) egy kód lekérdezésével helyreállíthassák a hozzáférést.
Összefoglalva
A hitelesítés mindig akadályt jelent. Mégis, ha a felület nehezen kezelhető, a felhasználók feltűnően kreatívak lesznek a szabályok elferdítésében, hogy működjön, és elfelejtsék a jelszót abban a pillanatban, amikor befejezik a tranzakciót.
Talán legalább egy esélyt kellene adnunk a felhasználóinknak, hogy megismerjék a weboldalunkat vagy alkalmazásunkat, mielőtt túl sok akadályt állítunk eléjük. Ideális esetben mindenki számára 2FA-beállításra van szükségünk, de előbb el kell jutnunk odáig. Az oda vezető út pedig egy zökkenőmentes, jó hitelesítési UX-szel van kikövezve – bonyolult szabályok és korlátozások nélkül.
