















| | | | Mottó: A csodagyerekeket úgy is lehet tekinteni, mint a tökéletes fejlődés példáit. Ezekben a gyerekekben több kritikus faktor szokatlanul jó összeilleszkedése hozza létre a különleges képességeket. /Dr. Gyarmathy Éva: A tehetség/ | 2025. január 15. | | | | KAÜ/Ügyfélkapu+: kétfaktoros katekizmus | | | | | A NIS 2, azaz a Directive (EU) 2022/2555 jogszabályban leírt rendelkezéseket 2024. október 18-tól kell alkalmazni. Az ehhez kapcsolódó magyar jogszabály a 2024. évi LXIX. törvény. Ez a jogszabály különböző szektorok szereplőire (mint pl. a közigazgatásra) ír elő mindenféle biztonsági követelményt az alapján, hogy az adott szervezet adott szolgáltatása 2024. december 31-ig milyen biztonsági osztályba került besorolásra. Az ennek való megfelelésről az első kiberbiztonsági auditot 2025. december 31-ig köteles elvégeztetni minden érintett. Ha pedig innen visszaszámoljuk az átfutási időket, akkor azt lehet gyanítani, hogy az új követelményeknek megfelelő funkciók 2025 elején - vagyis mostanában - kerülnek élesítésre nem csak a közigazgatási rendszereknél, hanem mindenhol máshol is. A jogszabályban az azonosítás és hitelesítés funkcióra is vonatkoznak követelmények: teljesítendő előírás, hogy egy "jelentős" biztonsági szintű rendszer az egyszerű felhasználók számára is "többtényezős hitelesítést alkalmaz a nem privilegizált fiókokhoz való hozzáféréshez". Az, hogy mi számít "jelentős" biztonsági szintűnek, az több szemponttól is függ: számítanak többek közt a szervezet elektronikus információs rendszerei, valamint az azokban kezelt adatok bizalmassága, sértetlensége és rendelkezésre állásának kockázata, illetve az érintett felhasználók számossága is (pl. legalább 20000 személynek nyújtja a szolgáltatást). Annyit mindenesetre biztosan lehet tudni, hogy az állam működéséhez szükséges szolgáltatásokat érinti ez a jogszabály, de a mellékletei több más szektort is felsorolnak, mint (kiemelten) kockázatos ágazat (pl. a vasúti közlekedés). Közvetett módon érintettek a NIS 2 miatt a pénzügyi ágazat szereplői is (mint pl. a bankok/hitelintézetek, biztosítók), hiszen rájuk a - pénzügyi ágazat digitális működési rezilienciájáról szóló rendelet és az AML által meghivatkozott - PSD 2 műszaki leírásai egészen konkrét követelményeket határoznak meg. Azt is lehet sejteni, hogy a jogszabályalkotók - az egyenszilárdság jegyében - minden más ágazat rendszerétől is hasonló biztonsági szintet várnak el, ami valamilyen módon pénzügyi műveleteket biztosít. A NIS 2 által érintett vasúti közlekedés ágazatban a MÁV elektronikus szolgáltatása jellemzően ilyen, hiszen online jegyvásárlást biztosít, a profilhoz kapcsolódóan akár tárolhatja is a bankkártyánk adatait, így a felhasználói profilhoz/fiókhoz való hozzáféréshez szükséges a többtényezős hitelesítés (a jelenlegi, statikus jelszavas bejelentkezés valószínűleg nem elégséges).
Mi számít többtényezős hitelesítésnek? A tudomány jelenlegi állása szerint tényezőnek/faktornak számít a tudás (pl. megjegyezhető statikus jelszó), a birtok (pl. chipkártya vagy más kulcstároló token) és a biometria (pl. arckép vagy egyéb tulajdonság, viselkedési jellemző, ami a természetes személyhez kötődik). A jelenlegi egytényezős (1FA) megoldásról kell tehát többtényezős (MFA) megoldásra váltani, azaz egy kéttényezős megoldással (2FA) a követelmény már teljesíthető.
Mire kell figyelni a különböző tényezők együttes alkalmazásánál? Fontos ügyelni arra, hogy a kiválasztott tényezőket egymástól függetlenül kell alkalmazni (pl. a chipkártyára ráírt statikus jelszó már nem biztosítja a függetlenséget). Ezen felül érdemes megjegyezni, hogy biometria esetén gondosan kell kiválasztani a pl. arcképfelismerő szolgáltatást, hiszen a face-swapping deepfake szolgáltatások és generative AI által akár valós időben létrehozott videók miatt sokkal fontosabbá vált az élőség megfelelő vizsgálata (ezt pedig még a NIST FRVT 1:1 listájában szereplők sem tudják mind). A biometria a birtokkal is párosítható, mint a FIDO (Fast Identity Online) eszközök esetében, ott azonban inkább ujjlenyomatot használnak, amihez az élőség vizsgálata mellett/helyett az olvasó szenzor minősége, az észlelt és tárolt pontok mennyisége is számít. A műszaki követelmények összhangban vannak a jogszabályokkal, bár a jogi megfogalmazások nem minden esetben teljesen azonosak, így érdemes további értelmezésért az ősforráshoz visszanyúlni. A PSD 2 szerinti erős ügyfél-hitelesítés legalább két tényező egymástól független felhasználása alapján történik, az eIDAS egyik végrehajtási rendelete szerint viszont egy "jelentős" biztonsági szintű felhasználó-hitelesítési megoldás legalább két, különböző kategóriába tartozó hitelesítési tényezőt alkalmaz, a NIS 2 jogszabály hazai adaptációjában a többtényezős hitelesítésnél az egyik tényezőt egy a rendszertől különálló eszköz biztosítja (és ez felel meg leginkább az ősforrásnak számító NIST Special Publication 800-53A Revision 5 dokumentumban a többtényezős hitelesítésnél megadott "separate device" követelményének).
Milyen többtényezős hitelesítési megoldásokat támogat a KAÜ? A Dáptv. (2023. évi CIII. törvény) szerint a természetes személyeknek 2025. január 15-ig át kellett térni a KAÜ (Központi Azonosítási Ügynök) mögötti DÁP eAzonosítás funkcióján alapuló vagy az emelt szintű kétfaktoros (kéttényezős) azonosítást biztosító Ügyfélkapu, azaz az Ügyfélkapu+ megoldásra. Az előbbi "magas" biztonsági szintű, míg az utóbbi alá tartozó több modul "jelentős" biztonsági szintűnek felel meg. A "magas" biztonsági szintű megoldások valamilyen HW-alapú (kulcs)tárolót (Secure Element a pl. SIM kártyában, chipkártyában vagy Trusted Execution Environment a pl. processzorhoz kapcsolódóan) használnak, míg a "jelentős" biztonsági szintűek az érzékeny adatokat SW-alapú (kulcs)tárolóban is tarthatják, így kevésbé kötődnek egy konkrét eszközhöz, lehet őket rugalmasabban, felhasználóbarátabban is működtetni. Természetesen, ez a nagyobb kényelem alacsonyabb biztonsági szinttel jár együtt, de még így is több védelmet jelent a felhasználónak, mint egy statikus jelszót használó bejelentkezés (ami "alacsony" biztonsági szintnek felel csak meg). A NIS 2 követelmények teljesítése miatt tehát elsődlegesen az egyszerűbb felhasználó-hitelesítési megoldásokat vizsgálják/vizsgálták meg az érintettek. A nagyok közül a Google fiókjainál már nagyon régóta van lehetőség többtényezős hitelesítésre (az "Account" menüpontnál a "Security" beállításokon belül lehet látni a támogatott "2-Step Verification" megoldásokat). Jelenleg elérhetők között van biometrikus adaton (pl. arcképen) alapuló ("Passkeys and security keys"), Push Notification Message üzenetben Google-fiókba bejelentkeztetett eszközre interneten kiküldött kódos ("Google prompt"), egyszeri jelszót helyben generáló alkalmazásos ("Authenticator"), SMS-ben SIM kártyára mobilhálózaton kiküldött kódos ("Phone number") és előre legenerált TAN (Transaction Authentication Number) kódlistás ("Backup codes") megoldás. A közigazgatás számára is nagyjából ezek a lehetőségek állnak rendelkezésre, de a biometrikus adaton alapuló felhasználó-hitelesítő megoldás pont kikerült a KAÜ mögül, ugyanakkor a Google-fiók megkövetelése sem lett volna szerencsés, illetve az előre generált TAN kódlisták is inkább csak a skandináv országokban ismertek és használtak, így megmaradtak azok a megoldások, amelyeknél az egyszeri, dinamikus jelszó valahogy generálódik és valahogy kiküldésre/megjelenítésre kerül a felhasználónak.
Az egyszeri, dinamikus jelszó generálódhat a kliens oldalán vagy akár a szerver oldalán is, ahonnan SMS-ben, e-mailben, Push Notification Message révén, képernyőn kijelzett QR kódban, periodic polling logikával (vagy más csatornán/protokollon keresztül) megszerezheti a kliens, azaz a felhasználó. Mindegyiknek van előnye is, hátránya is, akár kényelmi, akár biztonsági szempontból vizsgáljuk (pl. "okostelefonokon" egy kártékony alkalmazás könnyen kaphat olvasási joggal hozzáférést az SMS tárhelyhez, így az SMS legfeljebb "butatelefonoknál" jelent biztonságos megoldást; a Push Notification Message üzeneteknél köztes rendszerek - pl. Firebase Cloud Messaging - is szükségesek).
Az egyszeri, dinamikus jelszó generálódhat véletlenadatok alapján vagy lehet determinisztikus. Ez utóbbi szintén a pénzügyi szektorra vonatkozó PSD 2 jogszabállyal jelent meg - ld. "dynamic linking" fogalom, Commission Delegated Regulation (EU) 2018/389, Article 5 -, ugyanis egy adott fizetési tranzakció (vagy akár bejelentkezési művelet) paramétereit is le akarták fedni a jóváhagyásra használt egyszeri, dinamikus jelszóval. A KAÜ mögötti, "jelentős" biztonsági szintű Ügyfélkapu+ többtényezős felhasználó-hitelesítési modulok mind determinisztikusak: a kliens oldali - az egyszeri jelszót helyben generáló alkalmazásos - megoldás az időadat és a felhasználói kulcs alapján kerül kiszámításra (TOTP), a szerver oldali - az egyszeri jelszót távol generáló és e-mailben elküldött - megoldás az időadat és a felhasználói kulcs mellett az adott tranzakció egyéb paramétereit is figyelembe veszi (OCRA, ami a TOTP szabványra épülő challenge-response réteg). A külső fél, azaz az egyszeri jelszót bepötyögő felhasználó számára azonban ez a különbség nem látszik, a felhasználó szemszögéből nézve ez a determinisztikus adat ránézésre ugyanolyan, mintha csak egy egyszerű véletlenszám lenne.
Mik az előnyei és hátrányai az Ügyfélkapu+ többtényezős hitelesítési megoldásoknak? A TOTP, azaz a pl. Google Authenticator vagy RedHat FreeOTP mobilalkalmazással is használható megoldás műszaki hátteréről korábban már írtam (ld. KAÜ/Ügyfélkapu: időalapú egyszeri jelszó (TOTP)), de a lényeget megismétlem alább.
A TOTP előnye, hogy
- könnyebben védhető a pl. mobil környezetben futó malware-ekkel szemben, mint a - bármilyen mobil alkalmazás által kiolvasható - SMS tárhelyre érkező egyszeri jelszó,
- azonnal rendelkezésre áll (nincs hálózati késleltetés, mint SMS-nél),
- ingyenes (nincs szolgáltatói díj, mint SMS-nél),
- szükség esetén HW eszközt is lehet használni kulcstárolásra SW megoldás (pl. mobil alkalmazás) helyett,
- szükség esetén - egy szintén nyílt szabványos (IETF RFC 6287) - challenge-response réteg is könnyedén ráültethető (pl. banki szektorban lehet ez érdekes adott tranzakció jóváhagyása, elektronikus fizetési művelet kezdeményezése esetén),
- mellesleg quantum-safe (HMAC-en alapul a TOTP).
A TOTP hátránya, hogy
- valamilyen pl. mobil alkalmazásra van szükség, ami kiszámítja az éppen aktuális értéket, azaz
- nem elegendő az SMS tárhely megléte, így az egyszerűbb, régebbi telefonok számára nem elérhető.
Fontos hangsúlyozni azt is, hogy az egyszeri jelszó generálásához szükséges regisztrációs adat, azaz maga a - QR code-ban tárolt - kulcs érzékenynek számít, ugyanúgy kell vigyázni rá, mint a hagyományos jelszóra (és ugyanúgy érdemes "jelszófüzetben" feljegyezni, hogy probléma esetén könnyen elő tudjuk venni és helyre tudjuk állítani a környezetünket)! Éppen ezért az sem mindegy, hogy milyen (mobil)alkalmazást és hogyan használunk ezen kulcs tárolására és az egyszeri jelszó generálására! Érdemes azonban tudni, hogy a legismertebb, a Google Authenticator alkalmazás 2023-04-24 óta már nem csak helyben tárolja ezen kulcsokat, hanem a szerverre is feltölti, szinkronizálja a felhasználó Google-fiókjába. Ez megkönnyíti ugyan a felhasználó életét (pl. mobiltelefon cseréje utáni újbóli beállításoknál), de fontos tisztában lenni azzal, hogy így viszont a KAÜ/Ügyfélkapu+ felhasználó-hitelesítés erőssége attól (is) függ, hogy a kulcsunkat tároló Google-fiók felhasználó-hitelesítése milyen erős. Ha a Google-fiók csak egy egyszerű, statikus jelszavas védelemmel van ellátva, nem túl erős és/vagy más weboldalaknál is használt jelszóval, akkor nagyobb az esélye annak, hogy kitudódik/feltörik. Ha pedig a Google-fiókot el tudja érni egy esetleges támadó, akkor már meg tudja szerezni a KAÜ/Ügyfélkapu+ kulcsunkat is (ld. TOTP: Happy Birthday, unsafe Google Authenticator!). A legjobb, ha erős védelemmel látjuk el az Ügyfélkapu+ kulcsunkat tároló Google-fiókot és akkor megmaradhat a most már alapértelmezett "online" módú működés a Google Authenticator mobil alkalmazásnál. Vagy... Kikapcsoljuk a Google Authenticator mobil alkalmazás szinkronizálását. Vagy... Eleve olyan alkalmazást kell használnunk (Google Authenticator mobil alkalmazás helyett), amelyik biztosan "offline" módban működik. Itt azonban körültekintőnek kell lenni: vannak ugyan megoldások, de pl. a TOTP.app (https://totp.app/) szolgáltatásnak nem szívesen adnám meg a kormányzati kulcsomat, még akkor sem, ha oroszul megígéri nekem, hogy márpedig "isten bizony, cserkész becsszó" nem fogja szerver felé továbbküldeni azt (ld. "на нашем сервере ничего не хранится"). A Verifyr (https://www.verifyr.com/) szolgáltatás is csábítónak tűnik, de a weboldal jognyilatkozata nem ír a mögöttes szervezetről, a - pár hónapig érvényes, ingyenes - SSL/TLS web server tanúsítvány kiadásánál sem történt szervezeti szintű ügyfél-átvilágítás, a Windows telepítőn levő code signer tanúsítvány is csak self-signed, illetve a Cloudflare is elég jól elrejti, hogy valójában kihez kötődhet a domain/web server, maximum a domaint regisztráló tudhat valamit az illető szervezetről. (Az itt felsorolt, ügyfél-átvilágítási hiányosságok vonatkoznak az orosz TOTP.app mögötti szervezetre is.) Én inkább maradnék a nyílt forráskódú, "offline", portable Apache/PHP modulban futó script-emnél, ami kérésre kiszámolja az éppen aktuális egyszeri jelszót, de még egy jól beállított Google Authenticator vagy RedHat FreeOTP is megbízhatóbbnak tűnik egy ellenőrizhetetlen forrásnál.
Az OCRA, azaz a challenge-response réteggel kiegészített TOTP megoldás műszaki hátteréről is írtam már korábban (ld. OCRA: A kihívás elfogadva), de nézzük meg, hogy a KAÜ/Ügyfélkapu+ oldali beállításnál, az egyszeri jelszó e-mailes kiküldésénél ez mit jelent!
Az OCRA előnye (a TOTP előnyein túlmenően), hogy
- az adott tranzakcióra/műveletre vonatkozik a jóváhagyás (mert annak paramétereit is lefedi, megfelelve a "dynamic linking" követelménynek), azaz
- egy időablakon belül is lehet több tranzakciót/műveletet engedélyeztetni (alapértelmezetten 30 másodperc az időablak, de ennél jóval nagyobb érték is beállítható, ahol már nem mindegy, hogy külön-külön lehet-e egy-egy tranzakciót/műveletet engedélyeztetni).
Az OCRA hátránya (a TOTP hátrányain túlmenően), hogy
- valamilyen csatornára szükség van ahhoz, hogy a felhasználó megkapja az adott tranzakció/művelet paraméterei alapján kiszámolt "challenge" értéket (pl. SMS-ben, e-mailben, Push Notification Message révén, képernyőn kijelzett QR kódban, periodic polling logikával) és utána
- valamilyen interakcióra szükség van ahhoz, hogy a felhasználó megkapja az adott "challenge" alapján kiszámolt "response" értéket, azaz az egyszeri jelszót.
A pontosság kedvéért el kell mondani, hogy bár OCRA szabvány szerinti egyszeri jelszó jön létre a KAÜ/Ügyfélkapu+ e-mailes felhasználó-hitelesítő moduljánál, de mind a "challenge", mind a "response" a szerver oldalon kerül kiszámításra és e-mailben már csak a végeredmény, azaz az egyszeri jelszó kerül kiküldésre. Ennek az a magyarázata, hogy így egyrészt nincs szükség kliens oldalon másra (csak magát a levelezőszolgáltatást kell tudni elérni), másrészt egy időablakon belül is lehet több felhasználó-hitelesítési műveletet engedélyeztetni (minden bejelentkezési folyamatnál más-más egyszeri jelszó lesz a megkapott e-mailben). Azt is lehet látni, hogy egy bejelentkezési műveletnél ennél több előny nem is nagyon származik az OCRA protokoll alkalmazásából, de hosszabb távon gondolkodva, más tranzakció/művelet esetén ugyanez a KAÜ/Ügyfélkapu+ modul (eltérő paraméterezéssel) jó lehet akár PSD 2 szerinti pénzügyi műveletek jóváhagyására is (pl. DÁP eFizetés funkció és más online fizetési megoldás számára is érdekes lehet). Visszatérve a bejelentkezési folyamatokhoz, érdemes azt is megjegyezni, hogy az e-mailben megkapott egyszeri jelszót a levelezőszolgáltatáson keresztül éri el a felhasználó, amely levelezőszolgáltatás szintén támogathat (vagy akár kötelezővé is tehet) többtényezős felhasználó-hitelesítést. A Google-fiókhoz kötődő GMail esetében láttuk is, hogy a Google Authenticator (TOTP) az egyik választási lehetőség, de más szolgáltatásokat megvizsgálva is ez tűnik a legelterjedtebbnek (pl. Freemail is ezt használja). Ez viszont azt jelenti, hogy ha valaki a KAÜ/Ügyfélkapu+ miatt nem is szeretne Google Authenticator (TOTP) vagy más, ezzel egyenértékű (mobil)alkalmazást használni, akkor attól még lehet, hogy a levelezőszolgáltatás elérése miatt erre még szüksége lesz. Tulajdonképpen eggyel kijjebb tolódik a TOTP-alapú többtényezős felhasználó-hitelesítés határa. Az is igaz viszont, hogy a levelezőszolgáltatásoknál általában hosszabb lejáratú munkamenetek vannak, így ott ritkán kell ténylegesen bepötyögni az egyszeri jelszavakat, mert belépve marad a felhasználó.
Miképp vezetik be a közigazgatási/piaci szereplők a többtényezős hitelesítést? A többtényezős felhasználó-hitelesítési megoldásokkal a legtöbb felhasználó leginkább a pénzügyi szolgáltatásoknál találkozik a mindennapokban, szóval, ott ez egyáltalán nem újdonság, de a főiskolai/egyetemi hallgatók is Google Authenticator (TOTP) révén tudnak csak belépni a Neptun egységes tanulmányi rendszerbe, ahogy a közigazgatásban a KKSZB menedzsment felületénél vagy a közösségi médiában a Discord, Facebook szolgáltatásoknál is ezt kell használni, az IT szektorban pedig akár a kódkezelő GitHub portálról, akár a jegykezelő JIRA portálról van szó, szintén megszokott már, hogy egyszeri jelszavakat kell bepötyögni a bejelentkezésekhez. Sok közigazgatási/piaci szereplő tehát már bevezette a többtényezős felhasználó-hitelesítést saját maga. Ugyanígy meg tudják tenni mások is, akik most a NIS 2 jogszabály (vagy egyéb, saját döntés) miatt változást terveznek. A NIS 2 által érintett vasúti közlekedés ágazatban a MÁV elektronikus szolgáltatásánál - vagy legalább az online jegyvásárlást biztosító funkciónál - is valószínű, hogy hasonló megoldást vezetnek be. Ezt megcsinálhatják maguk is, de kézenfekvőnek tűnik, hogy inkább integrálódnak a KAÜ/Ügyfélkapu+ szolgáltatáshoz - a többi 200+ rendszerhez hasonlóan - mondván, "a közigazgatási megoldás tutira jó, akkor biztosan nem kapunk bírságot". Így ráadásul akkor nem csak a "jelentős" biztonsági szintű többtényezős felhasználó-hitelesítési modulok lesznek elérhetők, hanem a felhasználó akár a "magas" biztonsági szintű DÁP eAzonosítás funkciót is választhatja a KAÜ mögött.
Várható tehát, hogy a NIS 2 miatt érintett rendszereknél 2025 elején (ha még eddig nem történt meg) sok biztonsági funkció bevezetésre, módosításra fog kerülni, amelyek közül kifelé, a felhasználók felé talán a legjobban érzékelhető változás pont a felhasználó-hitelesítés, a bejelentkezés/jóváhagyás folyamatnál lesz tapasztalható. A közigazgatási oldal ezt a változást most meglépte, de érdemes lesz figyelni, hogy hol, milyen módon fognak megfelelni a követelményeknek. Mivel 2025. december 31-ig köteles elvégeztetni minden érintett az első kiberbiztonsági auditot, ezért akkor lehet majd egy jó elemzést készíteni arról, hogy melyik közigazgatási/piaci szereplő melyik rendszerénél milyen felhasználóbarát és biztonságos többtényezős hitelesítés került bevezetésre a NIS 2 miatt.
Kapcsolódó anyagok: Mellékletek:
A laptop/desktop környezetekre is vannak különböző megoldások az egyszeri jelszó létrehozására, mint pl. a KeePassXC. Van mögötte felelős jogi személy és fejlesztői kapacitás. De ha valaki még bennük sem bízik meg, akkor akár saját maga is írhat ilyen alkalmazást, akár 300 sor kóddal. Erre példának jó a TOTPnow nyílt forráskódú, "offline", "fapados" alkalmazás, ami Apache/PHP modulban futtatható Windows, Linux, macOS környezetben. (A jelen leíráshoz becsatolt zip csomagban Windows környezetre előkészített, akár pendrive-on is tárolható/futtatható portable Apache/PHP modulban található meg az alkalmazás, de az Apache web server és a PHP futtatókörnyezet egyéni telepítésével más operációs rendszeren is használható a kód. A szabvány szerinti paraméterek mind módosíthatók, de az alapértelmezett beállítás megegyezik azzal, amit az Ügyfélkapu+ vár, vagy amit a Google Authenticator is használ. A régebbi operációs rendszereknél, mint pl. Windows 7 szükséges lehet még Visual C++ futtatókörnyezethez egy telepítő elindítása, de az is megtalálható a csomagban: kattintás az /Apache/VC14_redistributable/vc_redist.x64.exe állományra).
A TOTPnow alkalmazás használata előtt egy dolog beállítására van csak szükség: a TOTP regisztrálása során kapott kulcsot - ez QR kódként vagy szövegként kerülhet kijelzésre/átadásra valamilyen csatornán - kell a kódban beállítani és a "jelszófüzetben" feljegyezni (szerkesztés az /Apache/ApachePortable/htdocs/hotp-totp/TOTPnow.php állományban levő "totp_key" paraméternél).

 A TOTPnow alkalmazás használatához az alábbiakat kell megtenni: első lépésben az Apache web server modult kell elindítani (kattintás az /Apache/httpd.bat állományra), második lépésben a PHP kódfuttatást megjelenítő böngészőt kell elindítani (kattintás az /Apache/totpnow.bat állományra), utána pedig már lehet is kérni az egyszeri jelszavak létrehozását. Érdemes az egyszeri jelszó létrehozása előtt egy inicializálást végrehajtani, hogy friss legyen az időadat, ami alapján számol az alkalmazás (kattintás a "RESET now" gombra). Ezután kell kérni a kiválasztott szolgáltatás (pl. Ügyfélkapu+, Google, Facebook, PayPal) - adott időpillanatban érvényes - egyszeri jelszavának létrehozását (kattintás a "TOTP now" gombra). Érdemes hangsúlyozni, hogy ennél a megoldásnál nem pörög folyamatosan az érték, nem kerül automatikusan kiszámításra az egyszeri jelszó (mint pl. Google Authenticator esetében), csak akkor és abban az időpillanatban, amikor azt a felhasználó a gombra kattintva kéri.



| | vissza | | | | |
|