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

Fórumok

É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.

Hozzászólások

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.

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!

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).

 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)

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.

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-

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.

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?

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.

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...

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?

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

Nemide

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"?