Az egyik legkedveltebb kétfaktoros authentikációs (2FA) módszer a belépéshez szükséges egyszerhasználatos kód (OTP, one time password) elküldése a felhasználó mobil eszközére SMS-ben.

Ennek a megközelítésnek utolérhetetlen előnye, hogy a felhasználónak nincs szüksége külön authentikációs alkalmazásra (pl. Google Authenticator, Microsoft Authenticator, Bitwarden Authenticator, Lastpass Authenticator, stb.). Egy ilyen alkalmazás telepítése, beállítása és az alkalmazásban tárolt hozzáférésekről biztonsági mentés készítése mind szükséges ahhoz, hogy a felhasználó hozzáférése biztonságban legyen, ami sokak számára nehézkessé teszi a folyamatot.

A kódot SMS-ben történő kiküldésével megkönnyíthetjük a felhasználóink dolgát, főként ha már eleve ismert a felhasználó telefonszáma.

Nézzük, milyen lépésekből áll egy kétlépcsős azonosítási folyamat SMS alapokon:

1. lépés – Bejelentkezési adatok megadása

A felhasználó a szolgáltatás bejelentkezési oldalán megadja az email címét vagy felhasználónevét, majd a jelszavát.
A Belépés gombra kattintva a rendszer ellenőrzi a hitelesítési adatokat, és elküldi az egyszerhasználatos kódot
SMS-ben a felhasználó profiljában megadott telefonszámra.

2. lépés – SMS lépcső az egyszerhasználatos kód (OTP, one time password) kérése

A jelszó helyes megadása után megjelenik a kétfaktoros hitelesítési képernyő a következő elemekkel:

  • „A fiókban megadott 3630*******123 végű telefonszámra elküldtük a belépéshez szükséges kódot.” szöveg

  • Egy bemeneti szövegmező, ahová a felhasználó beírhatja az SMS-ben kapott kódot.

  • Egy „SMS újraküldése” gomb, amely kezdetben nem kattinthatóan kiszürkítve jelenik meg.

  • A gombon pedig elindul egy 60 másodperces visszaszámláló.

3. lépés – Ha a felhasználó nem kapja meg az SMS-t

Ha a felhasználó nem kapja meg az SMS-kódot, két lehetősége van:

  • Megvárja, amíg a visszaszámláló eléri a nullát, ekkor az „Újraküldés” gomb aktívvá válik.
  • Rákattintva a rendszer új SMS-kódot küld a telefonszámra.
  • A gombnyomáskor már érdemes további tájékoztatást is megjeleníteni:
    • egyrészt arról, hogy a felhasználó készüléke esetleg kéretlen üzenetek mappában tárolhatta el a beérkező üzenetet (ez Android készülékek esetén jellemző).
    • valamint arról is, hogy mi az ügyfélszolgálat elérhetősége, ahol a felhasználó segítséget kérhet.
    • Pro tipp: a második SMS feladási hívásnál használhatunk eltérő API kulcsot is, hogy még kisebbre csökkentsük a hibalehetőségeket. Rendszerünkben lehetőség van alfiókok használatára: ha pedig egy alfiókban egy alternatív SMS szolgáltatást állítunk be, azzal elérhetjük, hogy a második üzenet kézbesítése ne a címzett saját szolgáltatójánál, hanem egy másik mobilszolgáltatónál kezdődjön. Így ha esetleg az elsődleges szolgáltatónál fennakadás vagy késés tapasztalható, azt már a második üzenetküldéssel is ki tudjuk szűrni.
  • Ha ismét nem érkezik SMS, a folyamat többször is megismételhető.

4. lépés – Belépés vagy alternatív hitelesítés

Ha a felhasználó végül megkapja a kódot és beírja, a rendszer bejelentkezteti.
Ha továbbra sem érkezik kód, általában megjelenik egy alternatíva:

  • „Más ellenőrzési mód kérése” (pl. email kód, backup kód, ügyfélszolgálat).

A fenti folyamatot persze sokféleképpen variálhatjuk, ezt a pontos körülmények (pl. a felhasználói kör) alapján érdemes meghatározni.

Regisztráció, a telefonszám ellenőrzése

A tévesztések elkerülése érdekében érdemes már a felhasználó regisztrációja vagy profilmódosítása közben a telefonszám rögzítésekor egy ellenőrző kóddal validálni, hogy a felhasználó biztosan jó telefonszámot adott-e meg. Így elkerülhető az egyébként gyakran előforduló elgépelésből vagy számok felcseréléséből adódó hiba, amivel a felhasználó könnyen kizárhatná magát a fiókjából (a téves telefonszám valódi tulajdonosa pedig kéretlen üzenetekkel találkozna).

Miért ne érne célba az SMS?

Ahogyan minden műszaki vagy informatikai megoldásnál, az SMS küldése során is felmerülhetnek akadályok.

Szerencsére mindezek nagyon ritkán okoznak problémát a gyakorlatban, de jó, ha ismerjük a lehetséges okokat:

  • fejlesztői szempontból az egyik legalapvetőbb probléma, ha valamilyen okból nem elérhető az SMS feladásához használt API:
    • Az egyik alapvető hibaforrás lehet, ha az SMS feladást kezdeményező szoftver/szerver és a mi SMS szolgáltatásunk közötti internetes hálózati útvonalon valamilyen hiba jelentkezik. Mivel az internetszolgáltatók aktívan figyelik az internetforgalmat, ezek általában viszonylag gyorsan (legkésőbb pár órán belül) megszűnő problémák.
    • A kiváltó ok lehet szolgáltatásunkban zajló karbantartás is. Ezek kis forgalmú időszakokban jellemzőek, így ebből adódó problémával ritkán lehet találkozni.
    • Minden fejlesztés egyik legfontosabb lépése a hibakezelés beépítése: a mi javaslatunk az, hogy a BIP!Kampány SMS API integrációja során építsünk be olyan módszert, amelynek segítségével kis idő elteltével próbáljuk újra feladni azokat az üzeneteket, amelyeket elsőre nem sikerült feladni (pl. 60 mp-enként újrapróbálva).
  • a következő lépcső maga a kézbesítés:
    • néhány havonta tapasztalható a különböző mobilszolgáltatóknál, hogy akár fél-egy napra is akadozhatnak szolgáltatásaik (akár regionálisan, akár országosan), vagy valamilyen torlódás alakul ki az üzenetforgalomban.
    • manapság ritkán fordul elő, de a felhasználó gyenge lefedettségű területen is tartózkodhat. Ennek gyakorisága szolgáltatótól is függhet, de manapság már elég ritkán tapasztalt probléma, hiszen egy SMS rövidke adatcsomagja akár gyenge térerő mellett is célbaér, még ha a szélessávú mobilinternet (3G, 4G, 5G) nem is elérhető.
  • függően a mobileszköz típusától különböző problémák merülhetnek fel az üzenetfogadás illetve üzenetkezelés során:
    • a legegyértelműbb eset, ha a készülék tulajdonosa letiltotta azt a telefonszámot, amelyről az üzenet érkezik. Ekkor az üzenetkezelő programban általában látszik a bejövő üzenet, azonban nem kap róla értesítést a mobil záróképernyőjén a címzett.
    • Android készülékeken jellemző, hogy a készülékgyártók lecserélik a Google eredeti üzenetkezelő programját, és sajátra cserélik. Ezek az üzenetkezelő programok nagyon változatosan működő üzenetszűrőket tartalmazhatnak, amik egyrészt valós problémát szeretnének megoldani, azonban a mindennapos, teljesen legális üzenetforgalomban problémákat okoznak azzal, hogy az ártatlan illetve ártalmatlan bejövő üzeneteket is “Kéretlen üzenetek” mappában helyezik el, és erről sokszor nem is tájékoztatják a készülék tulajdonosát. Az Android-os üzenetkezelő programok változatainak sokasága miatt ráadásként mind a szűrés minősége, mind a beállítások módosítása rengeteg formában előfordul.
    • iPhone-ok esetében egyszerűbb a helyzet, mivel a gyári (Apple fejlesztésű) üzenetkezelő program nem végez üzenetszűrést. Ezeken a készülékeken ritkán tapasztalunk problémát az üzenetek fogadásával.
    • a kis számban ugyan, de még mindig használatban lévő olcsó nyomógombos készülékek (ún. feature phone) klasszikus problémája leginkább az üzenettároló kis mérete: ha új üzenet érkezik, azt addig nem tudja fogadni a készülék, amíg a betelt tárolóból nem törlünk legalább egy régebbi üzenetet.