Technikai háttér-információk – mi is ez az egész?
Intró
Ezek az információk hasznosak lehetnek annak is, akik korábban már próbálkoztak Ügyfélkapu+ regisztrációval, akár telefonnal, akár anélkül, és nem jártak sikerrel, ezért ezzel kezdem, hogy aki már szétfrusztrálta magát, hogy használná akár a NISZ vagy a Google autentikátorát, de úgy sem megy – nos, ő is képbe kerüljön.
Emiatt, továbbá abból kifolyólag, hogy ezen információ idősebb polgártársaink számára is hasznos próbál lenni, akik esetleg nem liddeltek még processzort, előfordulhat, hogy slendriánul vagy kevésbé szabatosan fogok fogalmazni.
Kérlek, hogy nyugodtan javítsatok ki kommentben, de zokon senki ne vegye.
Akit viszont nem érdekel a filozófia, meg a technológia se, csak megoldást keres, de azt sürgősen, ugorjon eleve a 3. oldalra.
Majd visszatér a műszaki áttekintésre, ha megold(hat)atlan problémába ütközik. 
Technológiai be-ki-tekintés
Szóval a rendszer magját a HMAC-SHA1 algoritmus adja. Ebből a MAC-nak semmi köze nincsen az Ethernet kártyákhoz, a message authentication code rövidítése. Itt most nem vágnék bele egy kriptográfiai gyorstalpalóba – lehetséges, hogy erre más formában, itt vagy máshol sort kerítek, de ez most nem az a darab.
Az SHA-1 azonban biztosan többeknek ismerős.
Ez volt az az algoritmus, amit anno a Nokia használt az "újabb generációs" színes nyomógombos készülékein, és huszon-éve már, hogy – ma körülbelül leginkább 1080p-ben történő terep2-zésre alkalmas – videokártyákkal fejtették ki a kellően elvetemültek a telefonnak az úgynevezett NCK kódját a hálózatfüggetlenítéshez.
És szintén ez volt az, amelyet – a Google kezdeményezésére – 2014 vége után kivontak a TLS (SSL) tanúsítványok használatából is.
Ennek oka, hogy ez az algoritmus gyenge.
Ezt használja jelen témánk, az OATH TOTP is, ami a legtöbb mai kétfaktoros autentikáció gerincét adja (az SMS és az e-mail mellett).
A legtöbb probléma oka
Azért, hogy a gyengeségeit ellensúlyozzák, illetőleg megakadályozzák, hogy a generált kódokat valaki visszaélésszerűen letárolja, később felhasználja, úgy lett a módszer megalkotva, hogy minden egyes ilyen kód 30 másodpercig érvényes.
30 másodpercig.
Az ugye világos, hogy ha nálad 13:39 van, a szerveren meg 13:41, akkor a kódod már akkor 90 másodpece elavult volt, amikor legeneráltad.
Ha te már próbálkoztál "hiába" az Ügyfélkapu+ aktiválással, nagy valószínűséggel ez lesz a problémád – főleg az utolsó előtti lépésnél, amikor az autentikátor által adott kódot kellene elfogadja (rögtön azelőtt, hogy kiírná, hogy eszköz párosítás sikeres, és kiadná a törlőkódot), és nem teszi.
Erre van egy kiváló oldal, amely a https://time.is címen érhető el.
Ide látogatva (ha telefonnal akarnád használni az Ügyfélkapu+-t ill. az autentikációt, akkor a telefont kell ellenőrizni akkor is, ha belépni asztali gépről vagy laptopról akarsz) rendkívül hasznos információkkal gazdagodhatunk:
A kép tetején látható, hogy az én órám 9 perc 37 másodpercet sietett.
Emiatt nem is tudtam elsőre aktiválni a szolgáltatást.
Ha ez az érték +- 15 másodpercnél magasabb, akkor gondban leszünk.
Az Ügyfélkapu+ (vagy bármely más hasonló kétfaktoros azonosítás) beállításához és működéséhez is nélkülözhetetlen, hogy az óránk pontosan járjon.
Érdemes tehát elmenteni ezt az oldalt akár a kedvencekbe, és ha nem tudunk egy idő után egyszercsak belépni, először ellenőrizni az órát, és csak utána latolgatni, hogy esetleg "meghackeltek", vagy bármi hasonló.
Eddig tartott az alap hibakeresési bevezető.
Ha érdekel, hogy hogyan lehet megoldani a címben jelzett módon ezt a problémát, ne habozz, olvass tovább.
Ha pedig érdekel, hogy hogyhogy siet/késik a telefonod / géped órája, amikor.. – kérdések és válaszok az utolsó oldalon! 
Miért KeePassXC? Mi baj a telefonnal?
Kezdjük akkor rögtön a második felével.
Ez egy elsőre elképzelhetetlenül szerteágazó tematika. Ezt egy picit megkapargatnám, majd szétbontanám; meglehet, így is tömény lesz, pedig ez csak egy (erőfeszítéssel nem) elképzelhetetlenül elhanyagolható szegmense annak a komplex eko-szocio-pszicho-lógiai mutáns interdiszciplináris meg(nem)fontolás-halmaznak, amelynek minden második gondolatát érintik valamilyen módon az effajta (nem konkrétan csak ez) beavatkozások, avagy éppen trendek.
Mivel a teljesség igényét megalapozottan kizártam jó előre, ezért objektivitást vélelmezni vagy általam sugalmazni nyilván rövidlátó, illetőleg rosszhiszemű volna. Ezt látványosan elkerülendő először a saját legfőbb problémá[i]m fejtem ki.
Folytatólag azonban igyekeztem "gondolatébresztő", a szélesebb közönség számára – szerintem – megfontolásra érdemes nézőpontokat felvonultatni, ezzel kerülendő, hogy az "ötgéé – csipp – laposfőd – vízdéenesseamikróban" síkra sikerüljön pozicionálni magamat és másokat.
Kérem, hogy ezt mindenki tartsa tiszteletben.
A magam relativizálhatóan egoista síkján van pofám azt vélelmezni, hogy indokolatlanul sokat dolgoztam ezen a cikken ahhoz, hogy a sokunk számára – máshonnan – nem ismeretlen CRC / ECC nélküli, saccra 3-4 bites monológok szintjére devolválódjunk akár a komment-mezőben – legyen az akár az imént felsorolt, vagy akár a "boomer luddita" vonulat.
Miért nem telefon?
Társadalmi káros hatások
Én emlékszem még, amikor a fém hátlapos iPhone ("2G", classic) megjelent. Nálunk hivatalosan nem is forgalmazták.
Én akkor unalomig nyomkodtam, jailbreak-eltem, teleraktam mindenfélével..
Aztán meguntam.
És ma sem tudom elképzelni, hogy hogy lehet 5 éven keresztül nyomkodni.
Van okostelefonom, bizonyos célokra, de az egyetlen alkalmazás, amelyik hozzáfér az internethez, az a böngésző. Pont.
Létezik telefon-függőség; ebben a tudomány nagyobb része egyetért. Ott vannak viták, hogy pontosan mi az, ami még pont nem számít annak, és mi az, ami már igen.
Egy biztos: evolucionárisan senki nem halna ki attól, ha kevesebbet nyomkodná bármely hordozható képernyőjét.
Kiber-/adatbiztonság
Tegyük fel, hogy valaki "ért az informatikához".
Mondjuk jobban, mint egy power user, legalább annyira, mint egy mid-level rendszergazda.
Az asztali gépeden, laptopodon bármikor "foghatsz" valami kártevőt akár fizetős, akár ingyenes, akár háztáji, vagy manuális módszerrel.
A telefonodon erre nincs lehetőséged.
Ha egy 0day sebezhetőséggel "megtámadják" a kerneled, akkor abban a helyzetben vagy, hogy a támadó belelát, bele tud nyúlni a kerneledbe, bármely futó process-edbe, jó eséllyel a Google/Apple/Samsung stb. is.
Te viszont továbbra sem.
A mobileszközöd gyári védelme kiválóan megvédi az eszközön folyó bármit.
Tőled.
És gyakran pont ennyitől.
Hacsak nem root-oltad/jailbreak-elted a készüléket (amit egyre kevesebben szoktak) és rendelkezel valami gyorsreagálású beviteli eszközzel, amivel shell-parancsokat értelmes sebességgel tudsz futtatni (tudom, boomer vagyok – nekem a touchscreen nem az).
Tehát a gépeddel szemben, amit – szándék, hozzáértés, idő birtokában, szükség esetén – magas arányban lehetséges biztonsági szempontból felügyelni – ráadásul számos, akár ingyenes eszköz, kutatás, irodalom stb. rendelkezésre áll mindehhez –, a telefonod az a dolog lesz, amiről mindig neked lesz a legkevesebb információd, hogy azon mi történik.
És már jó pár éve tulajdonképpen globálisan ezt akarjuk eladni "a legbiztonságosabb"-nak..
Kézenfekvőség, biztonság
Ez valószínűleg filozófiai kérdés – nagyon sokan vannak úgy vele, hogy elképzelni nem tudják, hogy a toalettre elmennek a telefonjuk nélkül, míg én, ha ebben a hidegben lenn felejtem este az autóban, reggelig biztos nem megyek le érte.
De mi van akkor, ha beleejtjük abba a bizonyos vécébe?
Betörik a kijelzője?
Vagy csak lemerül?
Amíg az egyébként is 15+ napos határidővel ellátott állampolgári kötelességeinket kell teljesíteni, az nem tűnik tragikusnak.
Ha nincs nálam készpénz, se bankkártya, mert "majd fizetek a telefonommal" – az már felettébb kellemetlen.
De ha a rendőr igazoltatna, és nincs semmilyen okmányom, mert minden benne van a DÁP-ban..
..az – brit tudósok szerint – kifejezetten zavaró lehet.
És ha majd egyszer meg kell javíttatnunk a részletre vett 400 ezres telefonunkat, 250 ezerért, persze nem részletre, ahelyett, hogy vennénk akár egy ugyanolyan hibátlant használtan ugyanannyiért, mert csak abban van benne a valamilyen visszanyerhetetlen adatunk..
Ráadásul full-drive encryption-nel lekódolva, hogy még a flash/eMMC chipet se lehessen / legyen értelme önmagában kibányászni adatmentés célzattal..
Ezt, azt hiszem, nem szeretném átélni.
Társadalom-gazdaság-filozófia
Végezetül abba gondoljunk bele egy pillanatra, hogy tulajdonképpen azzal, hogy az állam úgymond csökkenti a kormánytisztviselők munkaterheit – nyilván EU-s nyomásra; az egész RRF alapkövetelménye volt a "kisebb állam", furcsállom kicsit, hogy ezen nem annyira akadtak fenn a nagy rétorok itt meg amott –, vagyis kevesebb kormánytisztviselőre lesz szükség, mert áttereli azt, aki hagyja, a DÁP-ba, azzal az állam biztosan megtakarít valamennyit.
Nekem ezzel, eddig, adott esetben nincs is problémám.
Azonban azt abszolút nonszensznek tartom, hogy effektíve ezért engem, mint vállalkozót, vagy éppen polgárt, könyvelőt, etc. kötelez arra, hogy a saját költségemen vásároljak okostelefont, meg mobilinternet-előfizetést.
Vagyis közgazdasági értelemben voltaképpen kiszervezi a feladatát, ezzel az állampolgárok szempontjából negatív externáliát hoz létre.
(Akinek élből az jut eszébe, hogy "mit vagy úgy oda, úgyis van telefonod is, meg mobilinternet-előfizetésed is", azt tudom mondani, hogy each to their own. Ha neked van két lakásod, amiből az egyik üres, nem fogsz automatikusan megörülni egy önkényes lakásfoglalónak csak azért, mert a másik, amiben éppen laksz, történetesen luxusszinten felszerelt, meleg és kényelmes, és/vagy kiváló helyen laksz.)
Szóval tessék akkor bátran szubszidizálni a mobiltelefonokat, meg az előfizetési díjakat, amennyiben valaki komolyan gondolja, hogy egy idő után csak a DÁP marad.
(Nekem azért ezt követően is lenne még aggályom. Gondoltátok volna?)
Miért pont ez a program (KeePassXC)?
Ezt a programot viszonylag régóta ( > 10 év) ismerem.
Használni sokáig nem használtam, ameddig egyszer az IT policy rá nem kényszerített egy ilyen használatára (és a jelszavának leadására ) az akkori munkahelyemen.
Volt egy elődje, az simán KeePass névre hallgatott. Az .NET platformon futott, elsősorban Windows-ra, de Mono runtime-al elfutott Linux (stb.) alatt is.
Én azonban megtaláltam ezt, és úgy gondoltam, hogy ezt fogom használni, mert natív, nyílt forráskódú, és biztos, hogy azt a változatot futtatom, amelyet én fordítottam.
Aki odafigyel mostanában a Chrome "böngésző" körüli sajátosságokra, meg a Google körüli bizottsági hercehurcára, az sejtheti, hogy ezt hogy kell érteni.
Később, kb. 2 éve a Facebook kitalálta, hogy túl híres és befolyásos vagyok 
és ezért most úgy dönt, hogy kitilt, és nem jöhetek vissza, csak ha beállítom ezt a kétfaktoros csodát. 
Nyilvánvalónak tűnt, hogy sem Google, sem Microsoft által buildelt valamit nem szeretnék felrakni pláne a telefonomra.
(Igen, Android. Nem, nincs rajta "Play Áruház". Fölösleges. Van PostmarketOS, van F-Droid.. Nem kell mindig a "moddolás" járjon a fejünkben. Az amúgy is pontosan ebből a szempontból – adatlopás, adatszivárgás – hatalmas kockázat.)
A Google Authenticator persze open source – csak hát ugye egy android appot nem olyan egyszerű lebuild-elni, mint akár egy GNU make / CMake alapú natív valamit.
Nosza, írtam hát erre egy programot. Sima parancssoros, C-ben, linuxon elfut, hibátlanul működik.
Ezt akartam tegnap estével bezárólag grafikus felületre adaptálni.
Legalább annyira a mások, mint a magam hasznára és pláne szükségére.
Nagyjából össze is állt a struktúra, hogy lenne, megismerkedtem a Gtk4 borzalmas újdonságaival ..
..amikor is kiderült, hogy az ám, de Windows-ra nem lehet már csak úgy programot kiadni, nem 1999 van, kérem!
Nem tudom, Win11 hányadik kiadása van, létezik, melyik milyen régióban volt már hajlandó feltelepülni, mit fogad el..
..vagyis kell digitális aláírás.
Extended Validation. 200 USD-tól fölfele.
Egy ingyenes programhoz?! Még mit nem!!
Aztán megtaláltam az Azure Cloud-on valami remote signing szolgáltatást, amihez nem tudom, milyen membership kell, meg ezekben és ezekben a régiókban érhető el, de nem tudják megmondani, hogy melyikbe kellene regisztrálni..
Ezzel el is ment a tervezett fejlesztési idő kb. fele.
És akkor beugrott.
Te, van ez a program, itt legel a gépemen évek óta. Nem tud ez véletlenül ilyet? – töprengtem el rajta.
Hát.. Azt írja az oldalán az egyik kérdés címében, hogy nem*.
Alatta meg azt, hogy hát mégis.
*Valószínűleg az első kérdésig jutottam 2 éve, azért csináltam magamnak hobbifeladatot.
Jó, jó, de akkor végül miért is??
• Támogat Windows-t, macOS-t és Linuxot egyaránt. Nincs vendor lock-in, nem kell ezt a részt "újratanulnod", ha pl. Macre váltasz. Vagy bármire.
• Nyílt forráskódú. Bárki, aki ért hozzá, meg tudja nézni, hogy nem "lakik benne" senki.
• Teljes a forráskódja. Bármely platformra le lehet fordítani nemcsak forrásból, hanem konkrétan abból a forrásból, amelyet leszedtél, és esetleg átnéztél. (Egy esetleges ISACA compliance igény / audit stb. során egy kritikus "beszállító" auditja, nyilatkoztatása, vegzálása máris kiesett.)
• De ha mégse lenne kedved, a hivatalos oldaláról lehet leszedni a támogatott platformokra build-eket, installerrel, mindennel, nem mindenféle anonim cowboy-ok biztosítják a NATO együttműködésen / a DMCA területi hatályán kívüli szerverekről ezek elérhetőségét, ha egyáltalán. Fogod, letöltöd a saját oldaláról, feltelepíted, és megy. Windows-ra, Mac-re, Linuxra egyaránt.
• Natív app, NEM Java. Az egy dolog, hogy így sajnos nem olyan gyönyörű, mint az ÁNYK, de emellett nem mindenféle teáscsésze ikonokkal kell telepítened, miközben figyelsz, hogy melyik az utolsó Java Runtime, ami az Oracle-től még nem igényelt hadisarcot, és/vagy még pont elfut vele; hasonlóan, nem kell 5 féle többszáz MB-os telepítőcsomagot tartanod, hogy melyikkel mi megy, és mikor melyik jelenti, hogy végzetes sebezhetőség van benne..
• Nyilván ingyenes is.
• Kellő biztonsággal védi a titkos kódodat. (NE felejtsd el az adatbázis mesterjelszavát, amit megadsz!!)
• Van benne TPM / ujjlenyomat-olvasó integráció (ha gyorsan felejted a jelszavakat és nem akarsz vele küzdeni)
• Nem obskurus módon valamilyen felhőbe, vagy eldugott mappába teszi az adatbázist, hanem ahova kéred.
Az adatbázist bármikor le lehet (és le is kell) menteni valahova máshova (jobb minőségű USB drive, másik gép stb.)
Miért nem jó a web app (totp.app), amit az Ügyfélkapu oldalán ajánlanak?
Ez is egy jó kérdés!
Mivel oda van írva, hogy nem küldi el az adataidat az internetre, kizárólag a te böngésződben lakik, ezért nem zavart különösebben, hogy az angol mellett kizáróan orosz nyelven érhető el. 
Viszont ugyanez az előnye egyben a legfőbb problémája is.
Ha a böngésződben törlöd az előzményeket, a helyben tárolt tartalmat, stb., és nincs totp app-os mentésed, akkor a kódod, és a lehetőséged (a bejelentkezésre) elveszett. Nincs elfelejtett jelszó. Vagy megvan a törlőkódod, és kezdheted elölről a tréfát, vagy séta van.
Ha valami megfertőzi a böngésződ, vagy meghiúsul valami egy frissítés során, esetleg újratelepíted, vagy eltávolítod, a kódod és a lehetőséged elveszhet.
Ha inkognitó-módban böngésznél – abban a pillanatban, hogy bezárod az utolsó (Firefox) vagy ugyanazt az (Chrome) inkognitó-ablakot, amiben ez a tab volt, a kódod és a lehetőséged biztosan elvész.
Ilyenkor – hasonlóan az első lehetőséghez, az összes többinél is – ha lementetted valahova a törlőkódod, futhatsz vele még egy kört.
Ha nem – kormányablak.
Remélem, sikerült meggyőzzelek, és vagy már korábban is használtad / használod a Keepass[X[C]]-t, vagy most belevágsz a telepítésbe.
KeePassXC letöltése, telepítése
A telepítőt a https://keepassxc.org/download/#windows linkről lehet letölteni.
Alapból a Windows változat tabja tölt be; a többi platform eléréséhez felül a megfelelő tabot kell kiválasztani.
A letöltés eseménytelen.
Ha azonban Windowsra telepítjük, akkor mindenképpen frissítsük le / telepítsük a javasolt Visual C/C++ 17 Redistributable Package-et a Microsofttól (link).
Ez (a felhívás, valamint a link) a letöltési oldalukon is fellelhető (ld. alábbi kép). Kiváló UX érzékkel megvalósítva a "MSVC Redistributable" szövegrész, amint elég szembetűnően felfedezhető, kattintható. 
A telepítés sem túl izgalmas. Ha az integrációs lehetőségek valamelyikét kívánjuk, tudjuk, hogy a gépünk stb. támogat olyat, vagy van olyan eszközünk, azt állítsuk be.
A böngésző-integráció egy érdekes dolog. Lehet vele kísérletezni, miután beállítottuk, amiért jöttünk, és lementettük az adatbázist. Hamarabb nem javaslom.
Ha mindezzel megvagyunk, ugorjunk is a lényegre.
KeePassXC beállítása
Indítsuk el a programot a telepítést követően.
Ha még nem használtuk a programot sosem, akkor új adatbázist kell létrehoznunk.
A fejlesztők azt javasolják a leírásban, hogy aki már használja jelszókezelésre a programot, az is hozzon létre új adatbázist, ne a meglévőben keverje a rekordokat.
(Ennek biztonsági/redundancia-, nem pedig technikai okai vannak. Ha valaki 10-ből 10-szer tudja, mit csinál, rakhatja a meglévőbe is simán. Én van, hogy hajnalban küldöm be a válaszokat, olyankor észnél kell lenni.)
A Create New Database funkcióra kattintva a következő felület fogad:
Ide írjunk be az adatbázisnak nevet (ez lesz a file neve is alapértelmezetten, .kdbx kiterjesztéssel).
A névnek nincs jelentősége – a lényeg, hogy mi (vagy aki használni fogja) megismerjük.
Lehetséges leírást is megadni, de az teljesen opcionális. Én üresen hagytam.
A Continue gombra kattintva továbbjutunk:
Itt mindent hagyjunk alapértéken (hacsak nem szeretnénk, hogy – mint a banki széfek időzárja – pl. 5 percnél hamarabb ne tudjunk belépni sehova. Ekkor nyugodtan adjunk meg 300 másodpercet az 1 helyett).
Ismét Continue, utolsó lépés a létrehozásban:
EZ EGY KULCSFONTOSSÁGÚ PILLANAT.
Itt MINDENKÉPPEN olyan jelszót adjunk meg, amit BIZTOSAN nem fogunk elfelejteni.
Ha elfelejtjük, marad a törlőkód (ha azt lementettük külön valahova ezen a programon kívül).
Ha nincs YubiKey-ünk, akkor az Add Additional Protection-el ne szemezzünk.
(Nincs rosszabb, mint még két random nevű "key" / seed file-t keresgélni valahol, ha nem felejtjük el lementeni. Ne adjunk meg "key file"-t az Additional Protection-ben. Ha megsérül, eltűnik, ugyanaz, mintha a jelszót elfelejtenénk. Itt is igaz, hogy a kevesebb néha több – főként, ha nem sejtjük, hogy mi az, amiről szó van.)
Végül nyomjuk meg a Done-t. (Amíg a két jelszó nem egyezik, nem aktív.)
Itt fogja a program felkínálni a Save As ablakot, az adatbázis első mentéséhez.
Jól nézzük meg, és jegyezzük meg, hogy hova mentjük, különösen, ha elmászkálunk az alapértelmezett helyről (ez platformonként eltér; Windows-on talán a Dokumentumok?)
Ha elmentettük, valahol itt tartunk:
Kattintsunk a felső eszköztáron a bekarikázott plusz gombra.
Némi szerencsével az alábbi ablakra (üresen!) lehetünk figyelmesek:
Ide beírhatjuk (nem kötelező) az ügyfélkapus felhasználónevet, és annak jelszavát is.
Ha tudjuk fejből, igazából értelmetlen.
Ha el-elfelejtjük, akkor jó helyen van itt.
Az URL sem kötelező – néha cserélődik, körbejár; én beírtam.
A Notes mezőbe csak indikatíve írtam, hogy oda kell visszatenni a törlőkódot.
A Title-t kötelező megadni (de nincs jelentősége az értéknek; lényeg, hogy a felhasználó tudja, hogy neki adott esetben az kell).
Ha a címet, illetve a kívánt adatokat kitöltöttük, nyomjuk meg az OK gombot.
Ezt követően ellenőrizzük, hogy a fenti Database menüben a Save funkció inaktív, tehát NEM lehet megnyomni.
Ha így van, ez így van rendjén. A program minden módosítás elfogadásakor, alkalmazásakor automatikusan menti és újratitkosítja az adatbázist.
Ha viszont valami rejtélyes véletlen folytán a Save aktív lenne, nyomjuk meg.
Ugyanaz a képernyő kellene fogadjon, mint a művelet előtt, csak a jobb oldali "táblázatban" keletkezett egy sor, amely zöld (aktív).
Most kezdődik a "trükkös rész":
Válasszuk a felső menüből az Entries > TOTP (majdnem legalul) -> Setup TOTP... lehetőséget.
Ha minden jól megy, a következő felület üdvözöl.
És itt most meg is állunk, és áttérünk az érdemi beállításra.
Ezt az ablakot hagyjuk nyitva.
Az Ügyfélkapu+-hoz az itt lévő, alapértelmezett beállítások (SHA-1, 30 sec, 6 digits) tökéletesen megfelelnek.
A "Secret Key"-t meg majd az Ügyfélkapu rendszerétől kapjuk.
A lényeg: Ügyfélkapu+ aktiválása
Ehhez első lépésként jelentkezzünk be az Ügyfélkapuba (a "simába") a hagyományos módon (felhasználónév és jelszó segítségével): https://ugyfelkapu.gov.hu
Itt emelném ki annak, aki esetleg egyből erre az oldalra tévedne valahonnan:
AZ ITT TÁRGYALT MÓDSZER NEM ALKALMAS ARRA, HOGY ÜGYFÉLKAPUT IGÉNYELJÜNK, HA MÉG SOSE VOLT OLYANUNK.
Kizárólag már meglévő, nem lejárt, nem letiltott, működő ügyfélkapu, és 01. 16.-i lejárással való fenyegetés esetén tudunk így eljárni.
Ha ez sikerült, kattintsunk az "ÜGYFÉLKAPU+ IGÉNYLÉSE" gombra.
Itt elvileg még nem lehet semmi gond.
Ezután egy újabb fölösleges oldal tart fel minket.
Az itt leírt / megjelenő zajjal ne foglalkozzunk; ehelyett nyomjuk meg szaporán a "TOVÁBB AZ ÜGYFÉLKAPU+ IGÉNYLÉSHEZ" gombot.
Ezt követően történik végre már valami.
Az alábbihoz hasonló megjelenést kell látnunk.
Ha így van, nyomjuk meg a "Nem tudom beolvasni a kódot" linket egyből.
Ne küzdjünk mindenféle telefon-kamerával, bővítménnyel; teljesen értelmetlen.
Ekkor a képernyőn látható QR kód lecserélődik egy betűk-számok kombinációjából álló karaktersorozatra ("zagyvaság", az ábrán bekarikázva, kék színnel írva).
Yahtzee! Erre van szükségünk.
Másoljuk ki a vágólapra.
Ezt követően térjünk vissza a KeePassXC-be anélkül, hogy itt bármit is elnyomkodnánk.
KÜLÖNÖSEN NE KÉRJÜNK ÚJ KÓDOT. SE MOST, SE KÉSŐBB, ameddig a folyamat be nem fejeződik (vagy meg nem hiúsul hibával).
Ellenkező esetben a következő lépéseket kezdhetjük elölről.
Ezt a nézetet hagyjuk itt békében. Vissza fogunk térni folytatni (a letakart alsó részével).
A KeePassXC-ben az előző ablak kedvesen várakozik ránk, ahogyan a legutóbb otthagytuk.
(Kivéve, ha elfelejtettük feltelepíteni/lefrissíteni hozzá a Visual C Redistributable Package-et, mert akkor lehet, hogy közben kipusztult. Ez esetben pótoljuk, mielőtt újraindítjuk, hogy ne vesszen oda adat.)
Kattintsunk a Secret Key mezőbe, és illesszük be az előző fosztogatásunk eredményét a vágólapról.
Elvileg a program korrigálja, de győződjünk meg róla, hogy nincsen szóköz stb. se az első betű/szám előtt, se az utolsó után.
Valahogy így fest:
Nyomjuk meg az OK gombot.
A program elmenti a változásokat, és ha minden jó, a táblában megjelenik egy óra ikon a korábbi (sansszal egyetlen) sorunkban a hasonló fejléc alatt.
Emellett függőlegesen középen, a kulcs ikontól jobbra lévő sorban (ami a korábban megadott nevünket/title-t tartalmazza) is megjelent egy óra.
Ha ezt látjuk, akkor már majdnem készen vagyunk!
Nyomjuk most meg a Ctrl+Shift+T kombinációt.
Ha minden rendben, egy hasonló mini-ablak (dialógusdoboz, form, ..) fogad.
Alul "fogy a folyamatjelző csík", megy a visszaszámlálás.
Váltsunk vissza az Ügyfélkapura.
Ez ugye ugyanaz a nézet, ahonnan az imént hoztuk a kódot.
Görgessünk lejjebb, és a pirossal bekarikázott két mező közül a felsőbe írjuk be Ügyfélkapu jelszavunkat.
(NEM A FELHASZNÁLÓNEVET! Az ide már sehova nem kell. Tehát felülre megy a jelszó.)
Ezután váltsunk át ismét a "visszaszámlálós ablakra".
Most várjuk meg, amíg a legközelebbi "csík" elfogy, ezután a kiírt szám megváltozik.
(Ha így teszünk, akkor van a legtöbb esélyünk idejében beírni a számot. )
Ha megjelent az új szám, nyomjuk meg az ablakban a Copy gombot.
Most viszonylag gyorsan vissza kellene váltsunk ismét az előző, Ügyfélkapus nézetre.
Itt a fenti képen bekarikázott két mező közül az alsóba beilleszteni, ami a vágólapon van (a szám lesz az – reméljük).
Ha sikerült, nyomjuk meg alul a nagy kék gombot.
Ekkor siker esetén az alábbi látvány tárul elénk.
Ha nem sikerült, akkor "nem értünk oda" elég gyorsan!
Ekkor az iménti, "várjuk meg, amíg a legközelebbi "csík" elfogy" résztől ismételjük meg a folyamatot.
FIGYELEM: a művelet azt írja, hogy "az eszközpárosítás sikeres volt", de MÉG NEM VAGYUNK KÉSZEN.
A bekarikázott kódot másoljuk ki.
Visszaváltva a KeePassXC-re, OK-val zárjuk be a visszaszámlálós ablakot, és a felső menü Entries -> Edit Entry.. lehetőségét választva hívjuk elő ismét a korábban már megismert ablakot.
Itt a Notes részbe illesszük be a törlőkódot, majd nyomjunk OK-t.
Ekkor ez az ablak bezárul, visszatér az előző "táblázat" jobb oldalt.
Vissza az Ügyfélkapura, kattintsunk a "Törlőkód letöltése" gombra, és az így keletkezett file-t mentsük el valami könnyen megjegyezhető helyre.
Ezután nincs más dolgunk, mint megnyomni a Befejezés gombot, és nézni az eredményt.
Ha azt írja, hogy "A SZOLGÁLTATÁS SIKERESEN MEGRENDELVE" (ez lehet, változni fog ), az azt jelenti, hogy teljes a siker.
Ha hibát kapunk, akkor lehetséges, hogy túl sokat molyoltunk a törlőkód elpakolászásával, és kezdhetjük a folyamatot elölről.
Ha nem, akkor bezárhatjuk a KeePassXC-t.
Ezután javasolt, hogy mentsük el valahova az adatbázisát onnan, ahova mentettük, illetve a törlőkód file-t is, katasztrófa esetére.
FIGYELEM!
SOSE másoljuk le az adatbázist (.kdbx file), miközben a KeePassXC-ben meg van nyitva!
Ugyan a gépünkön maradó példány nem, a másolat azonban lehet sérült (és ha épp írt bele valamit, igen komoly eséllyel az is lesz).
És ugye "informatikus", rendszergazda, rendszerüzemeltető, devops-os stb. alapvetés, hogy kevés annál kellemetlenebb dolog van, mint amikor akkor derül ki, hogy a biztonsági mentésünk nem ér egy szabadkai fabatkát sem, amikor vissza kéne tölteni (szükség nyílik rá)..
Nem kell bezárni a programot a másoláshoz. Elegendő a menüből a Database -> Close Database lehetőséggel "elengedni" az adatbázist a másolás idejére (a másolás végeztével, néhány másodperc múlva rögtön visszanyitható az adatbázis, ha szükség van rá).
Eredményes aktiválást mindenkinek!
Kérdések és válaszok
Hogyhogy késik/siet az órám? Mit tegyek?
A számítógépek óráit (is) vezérlő "hangvilla" vágású kvarckristályokat 25 fokon kalibrálták, és úgynevezett inverz kvadratikus hő-pontosság görbéjük van. Ez azt jelenti, hogy 25 fok alatt, és fölött is késni fog a RTC (hardver-óra) jele. Egy Casio karórában nagyjából 25-30 fok lehet fixen, ha nem süti folyamatosan a nap, és a viselője csuklóján van; a gép RTC-je azonban az 5 fokos fűtetlen irodában, és a 40 fokos panellakásban agyonhajtva, 60-70+ fokon is egyaránt késni fog.
Ennél sokkal nagyobb pontatlanság adódik abból, hogy az RTC (hardver "óra") adataiból a BIOS/EFI/UEFI bekapcsoláskor állítja be a teljesen külön működő, az alaplapi PLL órajel-generátorhoz kapcsolódó rendszerórát, amely aztán alapesetben a legközelebbi bekapcsolásnál fog megint ugyanebbe az irányba szinkronizálódni.
Fordított irányú "áttöltés" kizárólag időszerverrel való szinkron (ld. alább) során történik.
Márpedig az RTC fő célja az idő pontos tartása, ezért viszonylag egzakt módon látja el ezt az egy feladatát.
A chipset PLL-je viszont egyáltalán nem pontos milliomod másodpercre, hiszen számos egyéb dolga van – pl. a különböző buszok (PSB, FSB, rendszersín, UHCI/EHCI/xHCI, DRAM sín, PCIe stb.) órajeleinek előállítása, amit eleve nem mindig sikerül tökéletesen szinkronba hozni.
Mindezt anélkül, hogy valaki állítgatná a gyári alapértelmezett órajeleket, késleltetési ciklusokat. (Haverom mesélte, hogy látott valakiket, akik azt álmodták, hogy ezt csinálták. )
A tapasztalat az, hogy DELL szervereken, DELL, Lenovo desktop-okon (amik tapasztalatom szerint nem a legtrágyább elemekből kerülnek összeállításra) a nyári melegben, klíma nélkül heti 1 perc sietség (a klimatizált szerverteremben pedig heti 30 másodperc késés) simán előfordult már.
De azt hittem, hogy beállítódik automatikusan!
Természetesen ma már a legtöbb operációs rendszer automatikusan szinkronizálja az időt az úgynevezett NTP protokoll segítségével.
Ez elméletben teljesen jól hangzik, a gyakorlatban azonban előfordulhatnak vele különböző problémák.
A teljesség igénye nélkül néhányat kiemelnék.
Nem történik meg az automatikus szinkronizáció (kézzel működik)
Nekem évekig nem sikerült rájönnöm, hogy Windows alatt mikor is történik ez a szinkronizáció pontosan.
Néha történt, aztán elmászott, és az égnek nem akart helyrejönni.
Rányomtam a Sync Now-ra, az persze megoldotta.
Tradicionálisan az ilyen folyamatok rendszerindításkorra voltak beidőzítve.
Ma azonban a legtöbben nem indítják újra a rendszereiket naponta nem, hogy többször, de egyszer se; a magamfajta elvetemültek van, hogy hónapokig.
A telefonokról – amelyek olyankor a GSM/GPRS/EDGE/LTE hálózatról is tud(ná)nak időt kapni – nem is beszélve.
Hála Istennek, a Microsoft is tett azért, hogy a korábban napi többszöri üzemszerű rebootkat automatizált, és aggregát formában, valamelyest tervezhetőbb módon a frissítések kiadásakorra, minden hónap második keddje utánra időzítse. 
Ugyanebbe a kategóriába tartozik, hogy biztosan kell legyen késleltetés, illetőleg vélhetően szándékos kihagyás is a folyamatban.
Gondoljunk bele, hogy pl. a time.windows.com van (volt? 10 éve nem használok Windows-t életvitelszerűen) beállítva az összes létező windows-os PC-hez.
Látható, hogy egy nagyobb ország nagyvállalatai közül ha csak 15-20 százalék irodistái kezdik nagyjából ugyanakkor a munkaidőt, az is mekkora rendszerterhelést jelentene. De az is lehet, hogy ténylegesen kapacitás nincsen, és mivel a NTP UDP alapú, az UDP pedig ugye egy best effort protokoll – vagy odaér, vagy nem.
Nem érhető el az időszerver
Ennek is nagyon sokféle oka lehet.
Például a tűzfal. "Normál" körülmények között ez a leggyakoribb.
Beállítod az otthoni hálózatot véletlenül nyilvánosnak; VPN-t használsz, ami szűri; stb.
De lehet az is, hogy ha valaki úgy tunnelezik, hogy csak a TCP megy ki rajta, mint nálam. (Ennek lehet biztonsági, vagy technikai oka is.) Sajnos erre az esetre nincsen jól (vagy egyáltalán) bevált megoldás. (Töprengek rajta, hogy hogy lehetne elegánsan megoldani.)
Jó, jó, ebből elegem van. Oké, késik/siet, mit csináljak?
Ha Windows-od van, akkor menj be az óra beállításaiba, és nyomd meg a Sync Now / Szinkronizálás most gombot. Ezt követően fél-egy perccel ellenőrizd, hogy az eltérésed immár 0, vagy "határértéken belüli" (kézenfekvő módon 5 másodpercnél kisebb).
Ha azt írja, hogy a szinkronizálás hibába ütközött, akkor sajnos muszáj leszel megtalálni az okait. Próbálhatod például
• kikapcsolni a VPN-t, ha van (erre a rövid időre)
• átállítani a hálózatod "magánhálózat"-ra "nyilvános hálózat"-ról
• kikapcsolni a tűzfalat teljesen (szintén erre a rövid időre)
• újraindítani a gépet
Majd ezt követően ismét megpróbálkozni a kézi szinkronizálással.
Régi Debian (és társai) Linuxon, vagy ha valaki – hozzám hasonlóan – azzal kezdi a használatba vételt, hogy eltávolítja a systemd-t, potenciálisan bármilyen másik disztribúción, föl kell telepíteni az ntpd-t, vagy pedig az ntpdate-t (ami a legtöbbször eleve feltelepül) kézzel futtatni. Az ntpdate nem szinkronizál automatikusan. (De ha beteszed pl. cron-ba, akkor simán működik.)
Telefon esetében ilyenkor mindenképpen érdemes újraindítani – olyankor az NTP szervertől és a hálózattól is szerezhet pontosabb időadatot.
Ha ezen megoldások egyike sem járna sikerrel, akkor marad az, hogy elmélyülsz a potenciálisan napokig tartó hibakeresésben, és elátkozod a napot is, amikor kitaláltad, hogy nincs kedved az okmányirodában sorban állni.
Vagy ha ehhez nem érzed magadban az erőt, akkor bizony..
..kénytelen leszel kézzel beállítani az órát.
Ez ugyan nem feltétlenül nagy segítség, de nem is véletlenül hagytam a legvégére.
Mivel várhatóan a különböző EU-s szabályozások (NIS2, ..) és egyéb kiváló ötletek miatt egyre több faktorunk lesz a mindenféle bejelentkezéshez, és látom esélyét annak is, hogy egyre kevésbé precíz hardverünk (nyilván drágábban..), ezért nem árt, ha legalább az óraellenőrzést készségszinten begyakoroljuk. Sajnos.
Legyen az telefon, vagy bármi.
A weboldal (stb.) azt írja, hogy majdnem másodpercre pontosan egy (két, ..) órát késik/siet az órám, de látom, hogy jól jár!
Az egész órás időeltolódások szinte kizárólagosan DST (téli-nyári időszámítás) váltási problémából, vagy helytelenül beállított időzónából eredeztethető.
A modern operációs rendszerek az operációs rendszer (ha úgy tetszik [ne tetsszen – a szerk.],
Ha az SHA-1 ennyire nem biztonságos algoritmus, miért esett erre a választás?
Ennek oka a digitális kriptográfia legalapvetőbb összefüggésében rejlik: az algoritmusok erőforrás-igénye (legalább) egyenesen arányos a biztonsággal.
Ez logikus – valamihez minél kevesebb számítási teljesítmény szükséges, annál egyszerűbb egy adott, fix számítási teljesítmény birtokában "feltörni", visszafejteni (úgynevezett kriptoanalízis nélkül, a legegyszerűbb, "végigpróbálós" – angol kifejezéssel "brute force" módon).
Ez azonban azzal is jár, hogy a hordozható, ilyen célra használt, készített eszközök drágább processzort, nagyobb akkumulátort, rövidebb üzemidőt stb. jelentenek.
Márpedig a TOTP-t leíró RFC 6238 a HOTP RFC 4226 kiegészítése a bevezetője alapján, a HOTP RFC bevezetője pedig a megoldás szükségességét elsősorban a már akkor létező, egymással nem kompatibilis, nem csereszabatos hardver-tokenek problematikájával támasztotta alá.
Ezek az eszközök hagyományosan – túlzás nélkül; 2005-öt írunk – olyan komplexitásúak voltak, mint mondjuk egy autó centrálzár-távirányítója, egy kvarcjáték, vagy egy korabeli digitális stopperóra.
Ha a szabványosítás során a szerző rá akarta venni a hasonló eszközök korábbi felhasználóit (egy nagyobb irodában ugye lehet 2-500+ darab, ami csak egy vállalat / telephely), hogy váltsák le a megoldásukat, a "szükség nélküli" csere eleve nagy vállalásnak számított, az azonban abszolút indokolhatatlan lett volna, hogy fizessenek 8+-szor annyit a tokenekért.
Tehát el kellett futnia tömeggyártható stopperórákon.
Aztán ez a megoldás velünk maradt, a javaslattól immár húsz éven keresztül.
Elsődleges autentikációra ma már semmiképpen nem biztonságos.
Ilyen felhasználási célra – kiegészítő, második faktornak – azonban teljesen megfelelő.
Mire, hol használható még ez a (KeePassXC-s, vagy bármilyen egyéb TOTP/2nd factor) megoldás?
Van egy nagy előnye annak, hogy "régi", de de facto szabványos protokoll.
Lehet használni pl. Facebook, Google, LinkedIn, Github stb. második faktornak is.
Ezeknek azonban – ha nem szoktuk még meg – javasolt vagy külön adatbázist létrehozni, vagy pedig kínosan ügyelni arra, hogy nehogy egy meglévő sorban írjuk át a kódot, mert akkor a felülírt sorra VÉGLEGESEN elveszíthetjük a bejelentkezési jogosultságunkat.
Valójában államunktól abszolút rendes, hogy kapunk törlőkódot, és ha azt is elveszítjük, akkor még mindig beballaghatunk a kormányablakba, ahol nagy duzzogva kisegítenek, hogy végre ismét boldogan nyújthassunk be adóbevallást. 
Ezzel szemben a felsorolt szolgáltatók többsége, különösen az ingyenes szolgáltatás keretében (ha nem voltunk már előtte aktív prémium előfizetők) semmiféle támogatást nem nyújt a felhasználóknak!!!
Ezen közösségi stb. szolgáltatók többségénél ha egyszer aktiváljuk a második faktort (akár azért, mert ők kényszerítenek rá), majd ellopják a gépünket / elfelejtjük a jelszót a KeePass adatbázishoz / kitöröljük tévedésből/véletlenül, jó eséllyel örök búcsút mondhatunk meglévő fiókunknak, és reménykedhetünk, hogy nem tiltanak ki szabályzatszegésért, ha (nyilván másik e-mail címmel, telefonszámmal stb.) új fiókot regisztrálunk..
Egyszóval: ADATBÁZIS-MENTÉS!4!4!!!4! MINDIG, MINDENKOR!
---
Előzetesen ezek a kérdések, problémák merültek fel. Ha valakinek van közérdeklődésre számot tartható kérdése, tegye fel kommentben, és – ha itt lehet szerkeszteni/revideálni – beteszem.
(Illetve ha eszembe jut valami, amit már összegyűjtöttem egyszer gondolatban, csak elfelejtettem, akkor is.)
