/MEGOLDVA/ Ügyfélkapu+

Az MI ezt dobta:

Az Ügyfélkapu 2025. január 16-tól már nem lesz használható a hagyományos módon. Ehelyett két lehetőség áll majd rendelkezésre az elektronikus ügyintézéshez:

  1. Ügyfélkapu+: Ez egy kétfaktoros azonosítást alkalmazó rendszer, amely már most is elérhető. A regisztráció során hitelesítő alkalmazás (pl. Google Authenticator vagy NISZ Hitelesítő) használatával QR-kódot kell beolvasni. Az Ügyfélkapu+ biztonságosabbá teszi az ügyintézést, és új funkciókat kínál, például valós idejű értesítéseket és központi dokumentumtárat.

A második a DÁP. A hozzáértőket kérdezem, hogy mennyire biztonságosak a hitelesítő appok? Kikik ellenőrzik az appokat biztonság tekintetében? Valahogy nem tudok megbízni egyik olyan szoftverben sem, amit az államapparátus erőltet ránk. 

Mondjuk az egy másik izgalmas kérdés, hogy akinek nincs okos mobilja, az számkivetett lesz?

keepassxc használata megoldás.

Hozzászólások

Szerkesztve: 2024. 11. 16., szo – 08:04

Jézus...

Azért mert van rá lehetőséged, még nem kéne témákat nyitogatni.

Aláírás _Franko_ miatt törölve. 
RIP Jákub.
neut @

Bocsánat, de hadd védjem meg kikepzo fórumtársat:
- Ő legalább szakmai topicokat nyit, nem politikait, nem flame-t.
- Témái általában vidám perceket okoznak a tapasztaltabb IT kollégáknak. Amolyan "stand up comedy by HUP". (kikepzo ne értsd félre, nem támadásból, nem gúnyolódásból írom)
- Az ifjú padavanok (akik általában nem mernek megszólalni, kérdezni) is tanulhatnak a topicokból.
- Én speciel hiányolni szoktam a topicjait 2-3 hetente. Amíg nem nyit naponta új témát, addig nem érzem drámainak a helyzetet.

Véleményem szerint.

keepassxc tud totp-t es az opensource, offline app. telefon se kell hozza.

mondjuk egy necces dolog van a hw-es cuccal, az ora. mennyi idonkent kell (es hogy lehet) ujra beallitani? vagy mennyire pontos? ugye itt max par masodperc elteres ami belefer!   telonal vagy yubikeynel ez nem gond de egy offline onallo cuccnal igen

persze ennel tobb is kezelheto de akkor a szervernek kell kovetnie kliensenkent a clock skew-et es korrigalnia.

"ugye itt max par masodperc elteres ami belefer"

1 perc lesz az inkább. Amiket én ismerek TOTP szerver oldali megoldásokat, azok 3 db kódot fogadnak el egy adott pillanatban. Az aktuálisat, az előzőt (-30 mp) és a következőt (+30 mp). Ezen belül kell lennie a generáló eszköz órájának.

ez implementacio/beallitas fuggo, lattam en mar +-300 secet is es olyat is ami csak 1 kodot fogad el.  nyilvan a kerdes ebben az esetben az lenne, hogy az ugyfelkapu+ hany kodot fogad el ? illetve hogy a kivalasztott hw token oraja mennyire pontos? ha csak napi 5 masodpercet siet/kesik, akkor is 2 het utan ba..6od. ha napi 1 secet akkor 2 honap utan. pedig ezeket tobb evre veszik ugye.

hat igaz kb 15 eve foglalkoztam hw fejlesztessel, ott igeny volt hogy a panelen legyen egy pontos offline ora, mivel penzugyi tranzakciokat is kellett logolni az eepromba. akkoriban megneztuk sok gyarto rtc chipjeit, es ilyen 3-5 sec volt a vallalt napi pontossaguk kulon homerseklet kompenzacio nelkul. persze a gyakorlatban ennel valamivel jobban voltak de eleg nagy volt a szoras, es eleg nehez volt olyan megoldast osszerakni ami 1 honap alatt nem csuszott el perceket. ma mar mindenki elkenyelmesedett mert a netrol konnyu idot szedni, de offline a mai napig nem megoldott tudtommal a nagy pontossagu, homerseklet-fuggetlen idomeres.

Havi 12-15s mindenféle termikus kompenzáció, vagy hőntartás nélkül megoldható, lehet a kristályoszcillátort szándékosan 32768Hz fölötti frekvenciára hangolni, _és_ összehasonlító méréssel kalibrálni kvázi szoftveresen: adott ideig együtt járatják egy nagy pontosságú órával, amiből meg lehet határozni, hogy hány órajelciklusonként kel egyet kihagyni, hogy pontos legyen - ezt az értéket beégetik az elektronikába, stb.

igen ezeket en is tudom, mi is kalibralgattuk de az nagyon maceras tomeggyartasnal/bergyartasnal, es az sem biztos hogy utana hasonlo hofokon fogjak hasznalni/tarolni mint ahol kalibralva lett. a hontartas pedig nem megoldhato (gomb)elemrol.

es a havi 15s is sok lehet egy TOTP-hez, 2 honap alatt kicsuszik az idoablakbol.

Az RSA SecurID (az is időalapő OTP, nem tudom, mennyire követte a szabványt, ott a tokenbe valami három év volt bedrótozva, utána garantáltan megszűnt működni. A hasonló elven működő Safenet tokeneknél nem nagyon emlékszem hardveres limitre, úgy emlékszem, ennél tovább használtuk, és nem volt gond vele (vagy legalábbis azzal, amit én kaptam).

Szerk: Digipasst is használtunk több éven át, ott se fordult elő szinkronizálási gond - legalábbis nálam, de nem is hallottam másoktól sem.

Már kinek ne lenne így 2025-re okostelója? A hajléktalanoknak is van évek óta. Már tényleg csak annak nincs, aki technofób, technológiának ellenálló, alusipkás. Mindenki másnak van, 10-100 éves korig. Aki ellenáll, az meg ne keresse a kifogásokat, hogy ízé, neki nincs, mást nem hibáztathat érte. Írom ezt úgy, hogy én se vagyok az okostelók nagy híve, meg hogy minden szart már csak külön appal lehet intézni, meg mindenhez QR kódot kell olvasgatni, de nem próbálnék ellenállósat játszani, ma már annyira kell mindenhez. Még mindig inkább ez, mint hivatalokban időpontot foglalgatni, vagy sorszámot tépve órákon át sorban állni, meg papírozni, kéttanúzni, vérpecsétezni, stb.. Muszáj haladni a korral, mindig van, akinek ez nem tetszik, de az is mindig megtörik idővel, megszokja.

The world runs on Excel spreadsheets. (Dylan Beattie)

Ez baromság. Van egy korosztály (jellemzően idősebbek), akik nem technofóbok, de nem áll rá a kezük a tapicskolásra. Butafont még elnyomkodnak. Ellenben nem volna hátrány, ha be tudnának lépni néhány állami oldalra - pl. EESZT. De itt is vannak páran, akik tudatosan nem okostelefonoznak. OK, ők legalább nagy eséllyel számítógéppel rendelkeznek. És vannak bizony sokan olyanok, akikek nincs számítógépük, vagy éppen nincs elég modern számítógépük. Attól, mert te lenézed az XP-t vagy épp a Win7-et, meg ugye hamarosan a Win 10 támogatása is lejár, attól még sokan használnak ilyen gépeket. Velük mi lesz? (Van W7-re OATH-kliens?) Nem nagyon sokan, de véleményem szerint simán összemérhető akár a Linux-felhasználók számával ennek a csoportnak (nem okosteló, elavult OS-t használó gépes felhasználók) a nagysága.

- Butafonra is van TOTP shared secret olvasó + TOTP kód generátor
- Mivel a TOTP kód generálása szabványos, ezért egy csomó ingyenes megoldás van rá (https://authenticator.cc/, https://github.com/2fast-team/2fast, https://totp.danhersam.com/, stb.). Ezek egy része működik windows 7-en is.
- Egyébként ennyi: https://www.youtube.com/watch?v=VOYxF12K1vE

Így van, ugyanazt írtad, amit én, csak más szavakkal, meg próbálod mentegetni. Lényegében nem áll rá a keze, meg tudatosan nem okostelefonozik, azaz szándékosan és makacsul ellenáll, csak azért se című játékot játszik, így meg magára vethet, ha nehézsége van, saját magukat szopatják meg ezek az emberek. Ezt a nehézséget ők választják be maguknak, azért nem kell megsajnálni őket.

Még az időseknél sem tudom elfogadni a jajj, nem áll rá a keze. Nem is kell ráállnia, telefont felvenni épp úgy tud rajta, meg SMS-ezni, max. az unoka beállítja neki a kétfaktort, meg a hitelesítő appot, azt csak akkor használja, ha tényleg szüksége van épp rá, Facebookozni, meg chat-elni nem kötelező a telón, mint egy tininek. Egyedül akkor nem abszolválható, ha valaki vak, vagy parkinsonos, és tényleg annyira remeg a keze, de az ilyenkor már nem elektronikus, hagyományos sem tudja intézni a saját ügyeit, ilyenekhez már évtizedekkel ezelőtt is gondnokot rendeltek ki.

Nincs modern számítógépük, akkor vagy vesznek, nem drága, ha nem a legújabb hype gent veszik meg, hanem egy elfogadható teljesítményű, használtat vagy a régire hajlandók Linuxot rakatni, megszokni, azzal is abszolválható. Ha ragaszkodnak a Win7-hez, meg egyéb muzeális régiségekhez, akkor megint: magára vethet, tudatosan választotta be magának makacssággal a problémákat.

The world runs on Excel spreadsheets. (Dylan Beattie)

Erős véleménybuborékban vagy.

Még manapság is ott tartunk az okostelefonokkal, hogy ha valaki nyüstöli őket, akkor 2 dolgot tehet a tulaj:
- Hord magával akku bankot. Egyik ismerősöm múltkor megmutatta a szó szerint féltégla méretű cuccát.
- Töltési lehetőség közelében marad.

Define: sokat.

Továbbá gondolom te is tisztában vagy vele, hogy a mobil / wifi lefedettség és térerő, jel / zaj viszony erősen befolyásolja, hogy mennyire merül a mobil eszköz. Másrészt a környezeti hőmérséklet is erős hatással bír az akkumulátorokból kivehető kapacitásra és élettartamukra.

De ahhoz, hogy ügyfélkap+-ozz, meg kétfaktorozd, ahhoz NEM kell a telót egész nap nyomni, mint a hülye. Ez a töltési lehetőség is fura kifogás, a legtöbb ember nem nagyon tölt sok időt olyan helyen, ahol nincs vagy konnektor, vagy valami más töltési lehetőség (járműnél). Aki kivételesen ennek ki van téve, mondjuk a munkája, vagy valami kapcsán, az meg ahogy írod is, gondoskodik magának powerbanról vagy ami kell, abból sem muszáj féltégla feltétlenül, igényfüggő.

The world runs on Excel spreadsheets. (Dylan Beattie)

A tanulás is jó megoldás - a TOTP egy jól dokumentált eljárás egy megosztott titok és időpont alapján történő egyedi kód generálására. Ezt akárki kvázi akármilyen nyelven megírhatja - nem az algoritmusban vagy az azt implementáló szoftverben van biztonsági kockázat, hanem a megosztott titok biztonaságos tárolásában azon az oldalon, ami ennek használatával szeretné magát azonosítani. Szóval ebben a 2FA-ban az a kérdés, hogy a secret tárolásában mennyire bízol meg, hogy azt harmadik fél nem tudja megszerezni.
A GA (és a Microsoft authenticator is) képes a "felhőbe" a saját fiókba menteni a secret-et, ami a biztonság egyik "lába" miatt (rendelkezésre állás) jó (mivel van mentésed), a másik miatt (bizalmasság) meg  nem annyira (harmadik félnél is ott van az adat, igaz a felhasználói fiókhoz történő hozzáférés korlátozott, illetve a fiókot kezelő entitásnak nem érdeke az egyén ezen azonosító adatát felhasználni).

Ennél biztonságosabb az, amit a DÁP valósít meg, az ugyanis egy külön csatornán (outband) kérdés-válasz alapon működve a teljes azonosítást elvégzi, nem csak egy második faktort biztosít.

 

"és új funkciókat kínál, például valós idejű értesítéseket és központi dokumentumtárat."

Többek között az ilyen pontatlanságok miatt sem kell komolyan venni ezeket az LLM-en alapuló eszközöket.

Bocsi, hosszú lesz.

Hogy picit a kérdéseidre is válaszoljak:
- A hitelesítő appok pont annyira biztonságosak, mint bármelyik szoftver. Lehet bennük hiba - akár a szoftverben, akár a szoftverfejlesztési folyamatukban, akár a háttérrendszerben, ahová az app ment / dolgozik. Sőt, az appstore-ban is lehet hiba, ami kihasználható.
- Az appok ellenőrzőiről nem sokat tudunk nyilvánosan. Vannak az appstore-ok, amik ellenőriznek bizonyos részeket. Mindemellett egyik appot se láttam eddig, hogy nyilvánosan auditálták volna. Jó lenne, ha ezek az audit jegyzőkönyvek nyilvánosan elérhetőek lennének - és most lóg bilibe a kezem. Másik topicban már pedzegettem a Common Criteria (CC) auditot. Ezen kívül más auditok és plecsnik is léteznek.
- Flame nélkül: az államapparátus kontraszelektált. Nem a legélesebb IT arcok dolgoznak ott - tisztelet a kevés és lelkes kivételnek. A kevés kivétel azok, akik életben tartják az állami / állami kötődésű IT-t. Én pont az államtól várnám el, hogy a legmagasabb minőséget képviselje. Kis pénz + kevés ember + közbeszerzés = kis foci. Én se bízok teljesen az államban, főképp annak néhány képviselőjében. Ezért is kerülöm például a DÁP-ot.
- Okostelefon nélkül is lehet élni. A TOTP tökéletesen működik nélküle. Lehet Ügyfélkapu+-ozni is. Perpillanat. 10-20-30 év múlva ez változhat.

Az ilyen könyvet ellő baromnak útilapu kell, nem a teljes user/password/2. faktor... Aki meg odaadja mégis, azt megkérdezni, (ezt már írtam korábban is), hogy egy paksaméta üres A4-es papírt aláírna-e, és odaadná-e a könyvelőjének, mellékelve minden személyes adatát hozzá? Mert az adatok ilyen átadásával pontosan ezt teszi. És ebben az esetben az esetleg a könyvelője által elkövetett bármilyen tevékenységért ő lesz a felelős, mivel az ő identitásával történik, nem pedig jogszerű meghatalmazás útján a könyvelő identitásával.

 

Szerintem elkülönül a cég és a személy. A gazdálkodó szervezetek (cégek) számára van a https://cegkapu.gov.hu/ cégkapu. A cégkapu a szervezethez kötött és a szervezet képviselője regisztrál be a cégkapu szolgáltatásra. A szervezetet regisztráló adhat ügykezelői jogosultságot természetes személynek. Ilyen lehet a könyvelő. A könyvelő a saját, személyes ügyfélkapu azonosításával fér hozzá a szervezet cégkapu szolgáltatásaihoz. A kérdés akkor az, hogy a könyvelő miért is kérné (kérhetné) el bárkitől a személyes ügyfélkapu hozzáférését?

Azt hiszem értem, de ha egyéni vállalkozó lennék, akkor biztosan saját kézben tartanám a dolgaimat. Azt gondolom, inkább a rendszer hibája, ha nem hozza létre az egyéni vállalkozók részére a személyes és a vállalkozói tevékenységhez tartozó bürokratikus ügyek intézésének elkülönítését. Ha ez így van, akkor - ahogy írod is - olyan megoldást választ mindkét résztvevő, ami számukra a legkényelmesebb. Még akkor is, ha mindketten tisztában vannak ennek a kockázataival. Ergo, az államnak kellene megteremtenie a megfelelő megoldást.

"Még akkor is, ha mindketten tisztában vannak ennek a kockázataival. "

Az a baj hogy 10-ból kilencen nincsenek tisztában azzal, hogy a teljes üfk+ hozzáférés olyan, mintha egy paksaméta üres A4-es lapot aláírva a könyvelőjének a kezébe nyomna, hogy használja amikor és amire csak akarja. Ugyanis ha Gipsz Jakab identitásával csinál bárki bármit, ahova a KAÜ-s login (üfk+) jó, azért elsődlegesen Gipsz Jakab állampolgár lesz a felelős, és ha ő ezt vitatja, akkor neki kell bizonyítania(!) hogy az identitását nem ő használta fel.

Vmelyik nav fuzetbe benne van, hogy mivel eleve az ev-nel nincs olyan eles hatar a vallalozas es a maganszemelyes dolgok kozott (trivialis pelda: szja), ott nem megoldhato a dolog. Aki ilyet akar, annak jogi szemely kell, ott teljesen elkulonul.

Valószínű, hogy a NAV álláspont adózási szempontból megállja a helyét, de szerintem más az ügykezelés kérdése. Azt gondolom a természetes személy saját neve alatt egyik esetben egyéni vállalkozóként jár el, míg magánügyei tekintetében magánszemélyként. Ha jól tudom a gazdasági tevékenysége során fel is kell tüntetnie a nyilvántartási számát és az E.V. jelölést. Talán nem jelentene komoly nehézséget a kettő elválasztása az elektronikus ügykezelésben, ahogy a cégek esetében.

TOTP alkalmazással önmagában nem lenne probléma, a látszat ellenére nem kapcsolódik semmihez.
A baj akkor lehet amikor backupolni kellene a TOTP tartalmakat / kulcsokat. 

Gábriel Ákos

Ez is jó lenne, ha nem kerülne ennyibe:

 

Minden második vevő ennyit költ előttem a Aldi-ban. Csipszre és kólára.

Van annak egy diszkrét bája, amikor egy havi 1.5-2 milliót kereső programozó soknak tart 34e Ft-ot egy profi eszközért. Erre mondják, hogy aki rí, attól el kell venni.

Én "ügyfélkapu+"-ra ezt használom. Nekem bevált.

Vettem párat ajándék gyanánt az említett 1 és 10 profilos eszközökből. Androidos nfc-s telefonról viszonylag egyszerűen programozható token. (Külön szoftver a 2 típushoz.) Sőt, úgy látom az e-személyihez megvett Reiner SCT is viszi.

A gyártói adatlap szerint 4-5 év a tokenek élettartalma. Az viszont nem egyértelmű, hogy time-sync okokból milyen gyakran kell majd újraprogramozni a tokeneket.

Szerkesztve: 2024. 12. 07., szo – 05:17

ki ellenőrzi az appokat?

Ki ellenőrzi az appokat ellenőrzőket?

ki ellenőrzi azokat, akik ellenőrzik az appokat ellenőrzőket?

Ki ellenőrzi azokat, akik ellenőrzik az appokat ellenőrző ellenőrzőket??

Hosszú a sor.

A hozzáértőket kérdezem, hogy mennyire biztonságosak a hitelesítő appok?

Nem vagyok a tema szakertoje, de ha tegyuk fel tudom valahogy megtudom (backdoor az appban, stb.) a 2FA kodjaidat, azzal sokat nem erek, mert X perc alatt lejarnak es tudnom kell a jelszavadat vagy valamilyen masik faktort, hogy hasznalhassam a kodot.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Ha az app-ból/tól el  lehet vinni a secret-et, vagy maga az app "hazaküldi", akkor megette a fene az egészet - harmadik fél is bármikor tud 2. faktort generálni.

Ja, ez igaz, ott a pont.

Jolenne ha a Google Authenticatorban at lehetne nevezni a kulobozo QR kodokhoz tartozo cimkeket, az lehet egy fokkal nehezitene az ilyesmit. Pl. a xyz@domain.abc helyett xyx@sajat lenne a felirat, aztan sok sikert parositani a generalt szamot az accounttal.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Ne már. Ez komoly?

Sajnos igen :(

At tudok nevezni valami "code name" nevu mezot, ami az email cimet tarolja amihez az adott QR kod tartozik, that xyz@domain.abc-bol tudok csinalni xyz-t vagy akarmit, de pl. a roundcube 2FA eseten a generalt kod cimsora igy nez ki: Roundcube 2FA server.domain.abc: email@domain.abc, ami nagyon fasza ha tobb mint 1 db cimed van adott domain-en, mivel pont az email cim resz log ki es van helyettesitve 3 db ponttal... A hatterben levo "code name" atnevezheto, ami sehol sem jelenik meg, de ha ellopjak a kodot akkor gondolom ezt is viszik vele, de a cimsor ahol szinten szerepel az email nem nevezheto at.

MS Authenticator legalább ezt az átnevezést tudja.

Majd megnezem, mondjuk szivesebben hasznalok Google cuccot mint MS-t, nem mintha egyik jobb lenne mint a masik, de ha mar Android akkor maradjuk a Google-nel.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Az issuert (ami a példádban a"Roundcube 2FA server.domain.abc") az MS Auth sem fogja tudni átírni (szerintem így vannak tervezve).

Az más kérdés, hogy miért kell issuer-el (opcionális) generálni a qr kódot annak ami generálta és , hogy miért teszi bele a domain nevet is. 

"A második a DÁP. A hozzáértőket kérdezem, hogy mennyire biztonságosak a hitelesítő appok? Kikik ellenőrzik az appokat biztonság tekintetében? Valahogy nem tudok megbízni egyik olyan szoftverben sem, amit az államapparátus erőltet ránk."

- DÁP helyett kétfaktoros authentikációra ott a Google Authenticator, nem az államapparátus erőlteti rád és kiválóan működik Ügyfékapu+ -al, mint ahogy azt hangsúlyozzák is.

"Mondjuk az egy másik izgalmas kérdés, hogy akinek nincs okos mobilja, az számkivetett lesz?"

Aki digitálisan elmaradott az majd szépen besétál a kormányablakba ugyanúgy ahogy eddig is tette valószínűleg. Egyébként állítólag januárban jön egy új feature, hogy email-t is lehet majd 2FA-re használni az Ügyfélkapun. Akinek meg az se jó az menjen szépen a hivatalba.

Biztonsági szempontból egy desktop/laptop windows (mivel a linux desktop éve ugye még mindig nem jött el :) mindig sokkal elmaradottabb lesz mint egy pár éves normális telefon.

Ha nincs rootolva a készülék, nem egy utolsó kínai nevenincs hulladékról beszélünk hanem valami márkásabb eszközről, és nincs minden szemét apk telepítgetve kézzel rá, akkor arra hogy illetéktelenek bele tudjanak kotorni a google authenticatorba abszolút minimális az esély.

Asztali gépen bármilyen fertőzésnek nagyságrendekkel magasabb az esélye egy átlagfelhasználó számára. Ezért helyezik 2FA esetén a fókuszt valamilyen mobilkészülékre.

Azt meg tudtad hogy böngészőben is van tiktok? :)

A TOTP alól a secret-et el lehet vinni, le lehet másolni, semmilyen technológiai kötöttség/garancia nincs ezeknek a biztonságos/védett tárolására. Egy kérdés-válasz alapon működő 2. faktor esetén használt kulcspár privát fele tpm-ben csücsül - sok sikert hozzá, ha onnan ki akarod szedni.

Szóval 2. faktorban is vannak szintek/különbségek, már ami a biztonságot, illetve a biztonságos (és jogszerű) használat kikényszerítését illeti.

Egy rendes tobb faktoros auth nem abbol all, hogy ismersz tobb jelszot. Lenyegesen jobb, ha 1) ismersz valalmit (pl. jelszo, kulcspar stb.), 2) van valamid (limitalt mennyisegu, masolhatatlan fizikai eszkoz), 3) ismer valaki (fuggetlen, megbizhato entitas, pl. Jozsibacsi a portas vagy Cujo)

A TOTP kulcsa is csak egy jelszo. Innentol annyit is er, amilyen bonyolult, es ahogyan taroljuk.

Pontosan. A kivezetésre ítélt e-személyis (hardvertoken) azonosítás esetén egy egy példányban létező hardver birtoklása és egy PIN kód ismerete kellett a "boldogsághoz", a DÁP esetén (nem próbáltam ki, hogy ugyanazt az identitást fel lehet-e húzni több készülékre) kell egy megfelelő mobil, amit fel kell tudni oldani, és kell az usernév/jelszó, plusz a 2. faktor nem offline generált kód, hanem kérdés-válasz alapon megy, azaz lehetősége van azonosítani az eszközt is. (Tippelem, hogy itt is cert alapon, mint ahogy egy normális hardvertokennél).
A sima totp az csak annyival jobb a user/pass párosnál, hogy nem két, hanem három információt kell megismernie a támadónak, melyeknek a biztonságos tárolása kizárólag a felhasználón múlik - a "birtoklás"-t teljesen kihagyja a működésből.

A totp esetén a shared secret-et a mobil eszközödön "birtoklod" amit egy független csatornán (képernyő/fotó) juttatnak el hozzád, és a birtoklás tényét úgy tudod bizonyítani hogy a shared secretből egy adott időpontban mindketten generáltok egy kódot, és azt a kódot megosztjátok egymással. Ha ez egyezik akkor a birtoklás ténye igazolva lett.

E mellett szükség van a felhasználónév és jelszó párosra is, a totp kód ezt nem váltja ki, így lesz két faktorod.

A "birtoklás"-on én adott fizikai eszközhöz való kizárólagos hozzáférést értek, a totp esetén ez részben sem teljeszül (nem kell fizikai eszköz, és nem kizárólagosan az érintett férhet csak hozzá), és mivel a shared secret ismerete elégséges a 2. faktor generálásához, így én ezt sokkal inkább a "tudás" kategóriába sorolom - pláne, hogy megosztható harmadik féllel/megismerhető harmadik fél által, és onnantól kezdve ez a harmadik fél is teljes azonosítást tud végezni a rendelkezésére álló információk birtokában.
 

Ez egy nagyon jó kategorizálási kérdés és erről egy csomót beszélgettünk annó. Oda jutottunk hogy a TOTP egy valid birtoklás alapú (a kategorizálás nem fizikai, hanem birtoklásról szól, posession) faktor AMENNYIBEN a felhasználó ezt egy külön eszközön (pl. mobil alkalmazásban) tárolja és ennek a védelmét biztosítja (pl. olyan alkalmazást használ ami biometrikus azonosítást igényel a kódokhoz való hozzáféréshez). Ezt szabályzatban érdemes előírni.

Ebben az esetben nézzük a pontjaid:

  • nem kell fizikai eszköz: de kell, előírod
  • nem kizárolagosan az érintett férhet hozzá: de, előírod
  • megismerhető a harmadik fél által: csak ha megosztod vele, éppen úgy, mint ha felírod a jelszavad egy papírra

Kaspersky-nek van erről egy elég hosszú leírása egyébként.

https://www.kaspersky.com/blog/types-of-two-factor-authentication/48446/
https://www.kaspersky.com/blog/authenticator-apps-and-security/47426/

Ha nem kizárólagosan az érintett férhet hozzá, akkor az pont olyan, mint a jelszó - tudás, nem pedig birtoklás. Birtoklás: Csak és kizárólag nálam van, és kizárólag én tudom használni. Egy bájtsorozatot lehet ismerni, de birtokolni nem, mert akár szándékosan, akár támadás útján meg_ismerheti_ más is, és onnantól ő is ugyanúgy képes használni.

A telefonban vagy máshol védett módon (TPM, hardvertoken, amiben a kulcs helyben generálódik, és a kulcstár memóriaterülete nem érhető el kívülről, stb.) tárolt secret (pl. privát kulcs) használata az eszköz birtoklását igényli, és szoftveresen kell biztosítani, hogy a használathoz az érintett megfelelően azonosítsa magát. A telefonban tárolt secret annyira lesz biztonságos 2. faktor, amennyire a készülék feloldása illetve a kulcs hazsnálatához szükséges azonosítás biztonságos. Ugyanez van a TOTP-vel is: ott az a kérdés, hogy a secret mennyire védett módon kerül tárolásra (mindkét(!) oldalon, azaz nem csak a kliensen, ahol a kódot generálja valamivel, hanem a szerver oldalon is, ahol a kódot ellenőrizni kell)

 

Oké, de hogyan tudna bárki más hozzáférni? Van egy adott folyamat ahol tudsz generálni egy adott shared secret-et. Ezt be tudod olvasni, és csak és kizárólag nálad lesz meg. A te feladatod azt hogy ezt úgy tárold az eszközödön (ez lesz előírva) hogy ahhoz más ne tudjon hozzáférni, például pin kóddal vagy biometrikus azonosítással kell védeni (akár mind a telefont, mind az alkalmazást). Innentől kezdve ha elveszted az eszközöd akkor már nem tudsz belépni, tehát innentől - legalábbis szerintem - ez birtoklás alapú második faktor. 

Amit a neten találtam, ott is ezt írják:

One-time passwords, including TOTP, are a common possession or "something you have" factor and help increase the security of your users accounts.

https://www.twilio.com/docs/glossary/totp

Szóval kiváncsian várok olyan forrást, ahol azt írják hogy a TOTP az knowledge based.

"hogyan tudna bárki más hozzáférni?"

A telefonon is valamilyen fájlban tárolódik a secret, a desktop alkalmazásban is fájlba van lerakva. HA ezt a fájlt elviszik, akkor máris hozzáfértek a secret-hez, hacsak nem védi az alkalmazás kellően erős jelszóval/titkosítással.

A "valamid van" azt kellene, hogy jelentse, hogy valami, ami neked és csak neked van meg, aminek a hiányát, más általi hozzáférést észleled (nincs nálad, nincs meg, stb.) - ennek a TOTP csak úgy tud (nagyjából) megfelelni, ha a secret generálására(!), továbbítására és tárolására, valamint a kód generálására kifejezetten szigorú megkötéseket alkalmazunk. Na ezek nincsenek meg az átlagos desktop TOTP motyókban: ha lenne bennük ilyesmi, akkor például a kód generálása előtt egy kellőene rős jelszót kérne be az alkalmazás, hogy a secret-et fel tudja olvasni... (És máris _tudás_ kell, nem birtoklás...)

 

Igy van, ezért kell szabályzatban rögzíteni hogy a felhasználónak külső eszközt kell használnia és azt pedig védenie. Ezzel a megkötéssel lehet a megfelelelő biztonsági szintre emelni a TOTP-t. (valójában ugyanúgy le kell írni hogy a jelszavát se adja oda másnak, meg a mobil eszközén ne engedjen másnak pl. ujjlenyomatot rögzíteni, meg egy csomó más mindent is).

Elvileg a szerver oldalon is el kell tárolni egy másolatot (ha ez nem így van akkor javítsatok ki, én csak kliens oldalon használtam, de ez tűnik logikusnak).

Azaz ha te mindent meg is teszel a kliens oldalon, jó szoftvert választasz ami nem menti el a felhőbe, nem küldi haza, nincs benne sechole amivel ki lehetne nyerni, figyelsz rá hogy senki más ne fotózza le a QR kódot, meggyőződsz róla hogy titkosított csatornán kaptad, nem írod le sehova a secretet, nem jegyzed meg hogy esetleg részegen kifecsegd valakinek stb. akkor is lehet hogy a szerver oldalról kiszivárog.

Azaz - szerintem - a TOTP esetén rögtön két fél is ismeri a secretet, ezért shared, és emiatt már nem csak te kontrollálod hogy ki férhet hozzá.

TOTP esetén a szerver generál egy secret-et (random cucc) amit megoszt a másik féllel (általában QR kód formájában). Ezt a fél beolvassa egy authentikátor alkalmazásba. Amikor használni akarják akkor az authentikátor alkalmazás a secret-ből és az aktuális időből generál egy (általában 6 számjegyű) kódot, amit a felhasználónak meg kell adnia a szervernek. A szerver mivel tudja ki a felhasználó, ezért a felhasználóhoz tartozó shared secret-et "felolvassa", majd pedig ebből ő is ugyanúgy generál az aktuális időnek megfelelő 6 számjegyű kódot. Ezt összehasonlítja azzal amit a felhasználó beírt, és ha egyezik, akkor ez igazolja hogy a felhasználó is a közös titok birtokában volt, ha nem, akkor pedig nem. Mivel a kód egy időablakhoz tartozik (konfigurálható, általában 30 másodperc) ezért általában el szokták fogadni a -1,+1 időablakban generált kódokat is az óra elcsúszások/hálózati késleltetés miatt. Jobb helyeken pedig vizsgálják azt is hogy hányszor próbálkozott a felhasználó, és ha túl sokszor, akkor kitiltják a bejelentkezést.

Igen, ez így működik, tudom, használtam és egyébként nem kötelező authentikátor alkalmazással beolvasni. Az csak fakultatív, nem kikényszeríthető technikailag.

De amit leírtál abban ugyanúgy benne van hogy a te klienseden kívül a szerveren is el van tárolva a secret és én arra mutattam rá, vagy csak akartam, hogy ha te mindent is megteszel akkor is van egy másik fél - a szerver illetve a szolgáltatás üzemeltetői - aki hozzáfér a secrethez.

A szerveren lehet titkosítani a secretet, akár felhasználónkénti egyedi kulccsal, de erre neked mint mezei usernek nincs rálátása, ráhatása. Pont mint egy jelszó esetén. Ott is csak elhiszed/reméled hogy egy salted hash algoritmus eredménye kerül a neved mellé mint jelszó és nem clear text.

A user - és egy támadó - szemszögéből a TOTP secret egy "második jelszó". A támadónak nem a generált kódot kell megszereznie, hanem a shared secretet. Emiatt én nem tartom igazi második faktornak, hiszen elég a monitorra ragasztott cetlire egy új sorba felírni a shared secretet - ami meglehetősen rövid - és ugyanott vagyunk mint ahonnan indultunk.

Az egyetlen előnyét abban látom hogy a felhasználók szeretik mindenhova ugyanazt a jelszót használni és a TOTP kikényszerít egy kötelező egyedi "második jelszót". Így ha egy szolgáltatás kompromittálódik, akkor más login nincs veszélyben. Azaz ha a felhasználók nem tanulnak meg egyedi jelszavakat használni akkor ezzel lényegében kényszerítve lesznek. Ha jobban belegondolsz ilyen esetben maga a jelszó akár el is hagyható, hiszen a TOTP generált kódnak is elég. Elvileg.

 

Szerk: Ha emlékszel még a Digest authentication-re HTTP felett akkor az is shared secret alapon ment, de sosem terjedt el.

A totp secret-et annyi és olyan eszközre mented, amennyire és ahova csak szeretnéd, sőt később is bármennyi további másolatot létrehozhatsz vele, sőt ugyanott, még ugyanabban a pc-s böngészőben is generálhatod ahol a jelszavad is letárolva van. Ennyit a "második" faktorról.

Ehhez képest a dáp-os challange-response authentikáció fényévekkel biztonságosabb, azt nem tudod duplikálni, az e-személyis hardveres chipkártyás authentikációval van egy szinten, csak kényelmesebb.

dáp-os challange-response authentikáció fényévekkel biztonságosabb,

Csak amin fut az egész*, az teszi ugyanúgy a feladatra alkalmatlanná. 

Arról nem beszélve hogy

".....nagyjából másfél millió elektronikus ügyintézésre kötelezett van, akiknek a harmada vagy nem képes, vagy nem alkalmas ennek a feladatnak az elvégzésére, és van még egy olyan negyedmillió, aki nem hajlandó például digitális állampolgár lenni, pedig muszáj lenne neki valamilyen elektronikus intézési formát választania.Tehát komoly probléma van, mert az érintettek felének vagy képességbeli, vagy akaratbeli problémái vannak az egész átállással kapcsolatban, és azért van ez így, mert az állam rájuk nyomta ahelyett, hogy együttműködött volna velük" – foglalta össze Ruszin Zsolt. (Magyar Könyvelők Országos Egyesületének alelnöke )

Valahol -lehet nem itt, hanem a DÁPos topikban- nehezményezted az általam említett "erőltettet"  fogalmat. Úgy tűnik nem csak én érzem így.

A probléma a dáppal kettős, az egyik hogy nincs rá fogadó készség, a másik meg -s ez az én véleményem- hogy alapvetően téves a "biztonságos e-alaírás, hitelesítés" elképzelés a user mobilján.

Igen tudom, az egyik gyengíteni a másik erősíteni szeretné a "biztonságot", de ez az "egyik se" megoldás szerintem hibás,  s az ok az, hogy -szerintem- alapvetően nem lett tisztázva mi a cél.

Valahogy úgy ahogy, az egyszeri példa írja:

Juszuf elér egy bizonyos kort, így az apja úgy dönt megmutatja neki a nagybetűs életet, összeülnek, tanácskoznak a barátaival, és eldöntik befizetnek neki egy kurvára aki majd.... Elmennek hát tanácskozni, mint legyenek a részletek. Esznek, isznak vitatkoznak, aztán rájönnek a kurva drága, meg a rászánt pénz egy részét már el is ették, itták .......szóval marad a kecske. Juszufot persze nem kérdezték, idővel kiderül, hogy a kecskét** is Juszufnak kell majd fizetni. Ezért aztán Juszuf nem boldog, a "Vének"meg csodálkoznak miért, hisz ők csak jót akartak.

 

*Egy mindenre is használt, ki tudja mióta feltört, mobiltelefon, a biztonságos használatára alkalmatlan userrel egyetemben.

** frissítések miatt idővel jelentkező frissebb szoftver verzió igény miatti új telefon vásárlás.

A Ruszin Zsoltot azért érdemes idehozni, mert mint látszik képesek megbuktatni (felhígítani )az egészet. És akkor úgy jártunk, hogy elköltöttünk egy csomó pénzt, és nem történik semmi. (Juszufnak marad a marokmarcsa :))

Ahelyett, hogy az elején leülnek vele és megbeszélik mi legyen és hogy legyen. Az egésznek a fő közönsége az a másfél millió elektronikus akármire kötelezett user, akiknek jelentős része a Ruszin Zsolt által képviselt könyvelőkön keresztül kommunikál az állambácsival. A velük történő előzetes egyeztetést kihagyni óriási hiba volt. (Juszufot nem kérdezte senki)

Van egy érzésem, hogy ezért még fejek fognak hullani. Másfél millió embert (jó, felét) nem célszerű feleslegesen megharagítani. Ezt írtam a DÁP-os topikban is. Ott le lettem baszva lmo -által

" úgy beszélsz a dáp-ról, mint valami kötelező dologról, " igen, másfél millió embernek kötelező. (csöndben jegyzem meg, ezek mind szavazásra jogosult állampolgárok. Ovisok, akik nem szavaznak, nem elektronikus ügyintézésre kötelezettek)

nekik az a bajuk,

Tök mindegy mi a bajuk, sok embert képviselnek, "bajukat" figyelembe kellene venni. Megoldást keresni rá.

Akik a jogkövetés helyett trükközéssel használják az online felületet, azokkal nem igazán szabad egyezkedni - a jogkövető magatartást ki kell kényszeríteni, nem pedig a teljes rendszer biztonságát keresztbefosni. Ha nem tetszik nekik, hogy ahhoz, hogy jogszerűen járjanak el, nem elég az identitás lemásolása, akkor menjenek el kapálni vagy akkumulátorgyárba szalag mellé biorobotnak.

Azert lehetne ertelmesen is szabalyozni, illetve infrastrukturat biztositani hozza. Ez persze szaktudas, ido es penz. Tokeletes sosem lesz, valaki mindig dunnyog, de nem mindegy a munkapont.

A lakotelepen, ahova szulettem, faterom szerint ugy epitettek a jardakat, ahogy az emberek kozlekedtek (igy egy evig sarban maszkalhattak inkabb). De valahogy megiscsak gyozott az esztetika a tervezo/kivitelezo fejeben (gy.k. jobban tudta, vagy elveszett a masik vonalzo), es sikerult derekszogre huzni a vonalakat. Hat, a sok paraszt tovabbra is 45 fokban roviditett a fuvon keresztul! Aztan tarsadalmi munkaban (lett okosba betonkocka) epult par extra jarda. Persze taposoaknakat is telepithetett volna a varosi tanacs...

Vicces hogy jogkövetésről beszélsz, mikor a feladattal megbízott a törvényben előírt határidőket nem tartja be. Hány hónapja kellene kész lennie a nehezményezett funkcióknak? Most mondjam, hogy akik nem végezték el időben a feladataikat azok " menjenek el kapálni vagy akkumulátorgyárba szalag mellé biorobotnak". De nem mondom, mert ezzel a stílussal a kapálás után gaz maradna meg, mert annak szebb a virága és neki az jobban tetszik.

Honnan tudod, hogy nincs e-aláírás a DÁP-ban? De jure van, élesedett a funkció, csak épp nem mindenkinek. Az AVDH-t üzemeltető entitás nem tehette meg, hogy jogellenes módon tovább üzemelteti a rendszert, nem volt abban a helyzetben, hogy mérlegeljen.
A fejlesztőket meg tessék perelni, hogy neked x károd származott abból, hogy a DÁP-ban neked nem volt elérhető az e-aláírás funkció, és ezt semmilyen más módon(!) nem tudtad megoldani. Sok sikert hozzá.

Mivel törvényt sértettek, sértenek, nem nekem kellene perelni, ha nem az ügyészségnek hivatalból feljelentést tenni.

De jure van, élesedett a funkció, csak épp nem mindenkinek.

Amúgy meg ez a  "ma süt a nap, de csak az okosak látják" magyarázkodás elég szánalmas. A törvény -most ezért nem fogom megnézni, de úgy emlékszem- nem tartalmaz olyan kitételt, hogy csak a kivételes felhasználóknak fog elérhető lenni a meghatározott időponttól.

Ruszin úr valószínűleg nagy nyilvánosság előtt nem merte volna kijelenteni, hogy nincs, ha van. Többek között ezt nehezményezte, csak nem minden mondandóját idéztem. Azt,hogy törvény szerint megszüntettek valamit, mert a törvény szerint több hónapja kellene lenni a másiknak, de az nincs. Még egyszer, ez nem fejlesztői hiba, illetve csak olyan minőségben, hogy nem informálták a megbízót, hogy nem lesznek kész, szóval módosítani kéne a megszűnésről szóló törvényt.

Hogy ez miért nem történt arról vannak tippjeim.

Mert a sok balfasz kiadja a munkát nevenincs tanoncok tucatjainak, akik havonta cserélődnek és nekik nem fogja odaadni a saját ügyfélkapus jelszavát (amire meghatalmazása van az ügyfelaitől), mert az veszélyes. Mehet is a jó kurva anyjába.

Ezeknek semmi nem lesz jó, amig nem tudja az eddig követett security-nigtmare-t folytatni.

Aki meg nem érti, hogy ehhez képest akár a TOTP, hátmég a DÁP mekkora előrelépés, az nyilván teljesen fogalmatlan a témában.

Oké, ezt el tudom képzelni, hogy egy könyvelőirodában ez probléma, ekkor viszont valami csoportkezelés-szerű dolgot kéne a bevallási rendszerbe tenni, mert valós igény, hogy a vállalkozó ez esetben a könyvelőirodának adjon jogot a bevallásai elkészítésére. Ezen a DÁP se segít, csak tovább rontja a helyzetet.

Mármint én Kispista fogom meghatalmazni a havonta cserélődő kisiskolásokat vagy esetleg arra gondolsz, hogy az én általam megadott engedélyt fogja a könyvelő tovább delegálni minden jöttment hülyének a tudtom nélkül? Mert igazából egyik sem nagyon tetszik.

Kifejtenéd mindezen a helyzeten a dáp hogyan ront?

"Kifejtenéd mindezen a helyzeten a dáp hogyan ront?"

Úgy, hogy eddig az usernév/jelszó birtokában teljes identitás ott volt a könyvelőnél, illetve a TOTP esetén meg a shared secret és a usernév/jelszó "jár így", viszont a DÁP esetén egy eszköz - egy identitás (sajnos nem oda-vissza érvényes, azaz egy személyhez ha minden igaz, tartozhat több eszköz is), azaz vagy vesznek annyi telefont, amennyi ügyfél van, _és_ a digitális okmányt használják jogszerűtlen módon, vagy marad a törvényes mód, azaz a megfelelő meghatalmazás megadása adott ügykörre.

"a helyzeten a dáp hogyan ront?"

...

"vagy marad a törvényes mód, azaz a megfelelő meghatalmazás megadása adott ügykörre."

Akkor leforditom: nem ront, hanem segit.

De azért türelmesen, huszadjára is megkérdezem: aki tényleg segghülye és biankó csekket akar adni a balfasz könyelőjének (és az ő gyakornok hülyéinek, akiknek előbbi továbbpasszolja a munkát) rábizza kb. mindenét, az orovosi adataival egyetemben, tehát továbbra is (jogszerűtlenül) oda akarja adni neki adni a saját belépési adatait, azt miért nem adja oda az ügyfélkapu+ adatait? Mi köze ennek a dáp-hoz?

Tehát hogyan is rontott a helyzetet a dáp? Sehogyan.

"Tehát hogyan is rontott a helyzetet a dáp? Sehogyan."

Pontosan. aki se&&hülye könyvelő és/vagy ügyfél, annak copacs, de azok lesznek szívesek a rúdaszpirint torokra venni - mert megérdemlik. :-D A többi, értelmes embernek meg nem ront a helyzetén.

 

Az üfk+ _is_ ki lesz vezetve, ergo vagy DÁP, vagy semmi - jelenleg ez a roadmap, ha jól dekódoltam az eddigi infókat...

Neked az irodának, mint cégnek kellene meghatalmazást adnod (jogi személy? vagy mi a megfelelő terminus technicus), nem az egyes embereknek, akik ott dolgoznak. Nem tudom, hogy erre fel van-e készítve az állami rendszer.

A DÁP az úgy ront, hogy az eddigi jelszómegosztás helyett sokkal nagyobb hekk kell hozzá, vagy pedig magadnak töltöd fel a bevallásokat.

Hát túl nagy hack nem kell az ük+ -hoz. És igen az lenne a logikus, ha a vállalkozó/cég/adózó meghatalmazná a könyvelőt mint jogi személyt ő pedig meghatalmazná a dolgozóit. És azoknak is be tudná állítani, hogy kinek milyen jogosultság kell. A táppénz ügyeket nem kell látnia az áfa bevallást készítőnek stb..
Az nagyon szomorú ha erre nem lett felkészítve a rendszer, el sem akarom hinni.

Azok az emberek (nevenincs gyakornokok) egyáltalán nem dolgoznak hivatalosan ott, igy hiába is adnál meghatalmazást az irodának.

És akkor neked is még egyszer: a dáp nem vette el a lehetőséget a baromállatoktól, hogy a több éve létező ÜK+ belépési adaikat továbbra is megosszák a könyvelőjükkel és a hetente cserélődő gyakornokokkal.

De ha elvenné, akkor sem rontana a helyzeteten az (illegális) jelszómegosztás gátolásával, hanem segitené a normális működés felé terelni a komplett hülyéket.

Éppen ezért állok értetlenül, amikor valaki azt mondja a dáp "erőltetése" korlátozza a szerencsétlen hülyéket, ill. ebben a szálban a dáp tovább rontotta a problémát. Hogy rontott volna tovább bármit, amikor - mint emlited is - különbözik az ÜK+-tól. Akinek az kell, az nyugodtan használja azt.

Valószínűleg véleményed stílusának köszönhető (de inkább annak, hogy a fejlesztők is így gondolkodtak) a reakció és később az eredmény. Se TOTP, se DÁP, hanem emailes elfogadó kód. Meg egy csomó feleslegesen kidobott pénz.

Mennyivel egyszerűbb lett volna előtte egyeztetni, megállapodni, majd ha mégis sír valaki utólag, azt mondani, hogy pofa súlyba, megegyeztünk alá is írtad.

De az demagógia, hogy a fejlesztés előtt megismerjük a célközönség véleményét, felhasználási stílusát, egyáltalán milyen, mekkora nagyságú csoportok, milyen igényekkel. Persze, ez nem könnyű feladat. Mennyivel könnyebb az "Ezeknek semmi nem lesz jó," felkiáltással azt csinálni, amiről mi úgy gondoljuk jó lesz. Mi vagyunk az okosak, eldöntöttük ez lesz, eszi nem eszi nem kap mást.

Aztán jön a valóság, hogy ha sokan nem eszik, jöhet az újratervezés. Mondjuk ez is egyfejlesztési módszer, de kíváncsi lennék, egy piaci alapú appnál meddig működne. Mert így, hogy állambácsi kifizeti az újratervezést, úr nem nézi alapon. Így könnyű.

A célközönség véleménye az, hogy legyen olyan második faktor, amit tetszőleges számú emberük elérhet, hazsnálhat, amivel n dolgozójuk tud m ügyfél nevében bármit is csinálni - mert nekik az a kényelmes.
Ezzel az e-mailes bacakodással az lesz, hogy beregisztráltatják az ügyfeleknek a 2. faktornak a cegnev+ugyfel kukac gémélpontkom címet, ami egyébként a cegnevkukac gémélpontkom-ra esik be, és ahova az összes fostos dolgozójuknak bejárása van, annak is, aki már 1000 éve nen is dolgozik ott, mert ugye a fiókon jelszót cserélni azt nem... Mert az nem kényelmes...

A biztonság az nem a kényelemről szól...

A könyvelőcéges baromnak pont az a hasfájása, hogy nem tudnak bármelyik ügyfelük identitását használva dolgozni, ha az egy olyan második faktorhoz van kötve, amihez egy identitás - egy mobiltelefon alapon külön eszköz szükséges - nekik az kell, hogy bármelyik számkuakcuk bármelyik ügyfelük nevében el tudjon járni az eddigihez hasonló egyszerű és baromira sz@r módon...

Nem ennyire egyszerű a helyzet.
Egy példa:
Ha 100 ügyfél téged meghatalmaz (a te telefonod lesz a 2. faktor) akit könyvelsz, akkor mind a száz minden értesítése beesik a tárhelyedre, de nem igazán beazonosíthatóan (nem elég informatív levél tárgy).  Ha megnyitod (ami ugye kell, hogy megtudd mi érkezett), akkor kézbesített. Ami rossz vicc, ha egy hosszú hétvége előtt Csütörtök du. megnyitsz egy NAV üzenetet amire a a határidő három nap, tehát 72 óra, mert a NAV nem foglalkozik a munkanapokkal. Hogy is fogod teljesíteni? És ha nem hosszú a hétvége, de péntek du. nyitod meg, akkor is vélhetően ki fogsz futni a határidőből ami pénzbe  (bünti jár) kerül. Hogy mégy el 2 hét szabadságra (ja hogy ott hagyod a telefont és használja boldog/boldogtalan. vagy teríted a "titkot" ami a 2 faktor előállításához kell. 
Mind ez azért, mert a NAV 3 napot és nem 3 munkanapot ad. -- meséli egy könyvelő.
Mesélt mást is. Lenne itt mit rendbe tenni. Mert annak lemodellezése, leképzése sem sikerült, hogy a magánszemély és a jogi személy az nem ugyan az, és egy jogi személyben több magánszemély kell(het), hogy ügyeket intézzen. 

Ja értem, a ios és androidos telefonok rettentően nem biztonságosak, viszont a lopott, crackelt, összetákolt windows-ok, na azok aztán nagyon biztonságosak...

Az erőltetést az idézett baromsággal sem sikerült alátámasztanod. Azt irod van másfél millió ember, aki e-ügyintézésre kötelezett, aminek a fele szellemi fogyatékos a másik fele meg "nem akarja". (a maradék 750.000 embernek semmi gondja a rendszerrel)

1. Akkor menjen kapálni, alkalmatlan a munkájának elvégzésére.

2. Hogy jön mindez a DÁP "erőltetéséhez"? E-ügyintézésre kötelezett. Az nem csak a DÁP, ott van az ügyfélkapu+ is, ami a FUD-dal ellentétben, nem szűnt meg.

Hogy a még ki sem jött, senki által nem ismert működésű, dáp-os e-aláirásról milyen lázálmaid vannak, azzal továbbra sem kivánok foglalkozni. Egyelőre arról tudunk beszélni, ami kijött és működik. Ügyfélkapu és közszolgáltatókhoz való belépés, ill. rendőri igazoltatás. Ezek sokkal biztonságosabbak és kényelmesebbek dáp-pal és jól is működnek.

Jelenleg _sem_ szabad más identitásával bejelentkezni a magyaroszagponthu-ra és az ott elérhető szolgáltatásokat igénybe venni. Aki nem óhajt jogkövetően eljárni, az tényleg takarodjon kapálni... (Ugye ha itt keresztbetosszák a jogkövetést a könyvelőcégek, akkor vajon a munkájuk során hányszor és milyen súlyosan teszik meg ugyanezt...? )

Látom továbbra is szajkózod a saját igazságodat, és nem zavar a valóság. Ahelyett, hogy elmentek volna kapálni, érvényesítették az erejüket, és kibulizták, az email-es verziót. Ha valóban szeretnéd elérni a biztonságos autentikációjú digitalizációt, esetleg, hogy megváltozzon az"odaadom az emailcímet meg a jelszót" módszer, nem kéne elgondolkozni, hogy ezzel a gondolkodásmóddal ezt nem fogod elérni. Ha célt akarsz érni máshogy kellene csinálni? Esetleg kommunikálni velük, időben, letéve sarokpontokat (már pedig az "odaadom az emailcímet meg a jelszót", továbbiakban nem fog működni), de hagyva nekik lehetőséget, a rendszer saját igényük szerinti apró módosítására. Időben. S mikor ez megtörtént, akkor nekiállni fejleszteni.

No, ma direkt rákérdeztem hogy ez most hogy működik. Van a könyvelő ügyfele. Ő a Magyarország.hu-ra belépve tud meghatalmazást adni a könyvelőnek, méghozzá nem csak bianó bármire, hanem adott területre (pl. csak könyveléshez kapcsolódó területhez). Ha a könyvelő belép a rendszerbe, akkor onnantól kezdve látja az ügyfele adott területhez tartozó adatait és ott műveleteket is tud végrehajtani.

Itt (a ügyben siró könyvelők és sajnos itt a topicban is) olyan szintű műszaki/biztonságtechnikai analfabétizmus van, hogy ez esetben pont nem az ő teljesen agyament, security-nightmare működésükhöz kell igazitani egy állami, kritikus infra biztonságtecnikáját, hanem igenis be kell vezetni az industry standard technológiákat, akkor is, ha hülyéknek nem tetszik, mert nem tudják tovább művelni a hülyeségüket.

A meghatalmazás/delegálás lehetőségét kellene hozzájuk igazítani (adott vállalkozásnak is lehessen meghatalmazást adni, amelyet a vállalkozás felelős vezetője delegálhat a munkatársaira, mely delegálásért teljes egészében ő felel.), és természetesen aki ilyen munkakörben dolgozik, az fogadja el, hogy a 2. faktor az a DÁP - vagy, és ez sem lenne hülyeség: nem kivezetni az e-személyis azonosítást, legalább adott kör számára.

 

Ez szerintem két párhuzamos probléma.

Az egyik az, hogy hogyan authentikáljon a felhasználó. Jelenleg egy user/pass van, ehhez képest a TOTP, DÁP, minden is egy baromi nagy előrelépés.

A második probléma az authorizáció: az hogy a könyvelőknek támogatnia kell a könyvelőcég ügyfeleinek (továbbiakban ügyfél) munkáját, ehhez pedig arra van szükség hogy az ügyfél helyett különböző interakciókat hajtson végre az állammal. Az ügyfél azért fizeti a könyvelőt hogy ezt megcsinálja. Ezt jelenleg úgy oldják meg hogy az ügyfél megadja a felhasználónév/jelszavát!!! a könyvelőnek, aki igy el tud az adott személy helyett járni. Nyilván ez egy security rémálom. 
A megoldás itt az hogy adott feladatra lehessen engedélyt adni, amit lehessen/ne lehessen delegálni, pont az általad leírt use-case-ek miatt. Innentől kezdve pedig loggolva legyen hogy ki és mit csinált, és ez látható kell legyen az ügyfele számára.

Az e-személyi szolgáltatás az égadta világon nem segít a történeten.

> úgy oldják meg hogy az ügyfél megadja a felhasználónév/jelszavát!

az az ugyfel hulye.

> megoldás itt az hogy adott feladatra lehessen engedélyt adni

lehet, mar legalabb 15 eve. mikor konyvelot valtottam az uj elem tolt egy nyomtatvanyt (akkor meg papiron) amin be lehetett X-elgetni milyen ugyekben adok neki meghatalmazast, es azota is o intezi az osszes adougyet, sose adtam meg senkinek a jelszavam.

a problema - amiket eddig olvastam - inkabb ez:

1. ma mar elektronikusan kell a meghatalmazast is benyujtani, ehhez sok (uj) ugyfel hulye, de ehhez eleg lenne 1x beirnia a konyvelo elott a jelszavat az beadja es kesz.

2. allitolag vannak olyan ugyek amire nem lehet meghatalmazast adni, de nekem 15 ev alatt nem volt ilyen amire keves lett volna

3. nem a konyveloceg hanem 1 szemely (pl a fokonyvelo) szamara adjak a meghatalmazast, es o nem tudja tovabb delegalni a tobbi konyvelonek, igy igazabol a fokonyvelo jelszavat/kodjat (es nem az ugyfeleket) hasznalja mindenki a konyveloirodaban...

Most is van meghatalmazas funkcio a konyveloknek. Egy hibaja van, hogy megha ceget hatalmazol meg, ott is csak a vezetonek ad erre jogot, nem pedig a ceg mint jogi entitas kap (aki hozza tudna arni ehhez a dolgozoit). Ez a hiba amit javitani kene, de a konyvelok szervezete se ezt nyomja…

Egyetértek, pontosan ez a hiba. Ugyanakkor azt is érdemes látni hogy ennek a megoldása nagyon bonyolult (lenne).
Nem csak a fejlesztés hanem az üzemeltetés is. Nem csak a konkrét kiszolgálás (x-nek van-e y-hoz joga) hanem a folyamatos karbantartás is. Én láttam (bankban) ilyen rendszert, irdatlan pénzbe kerül.

Aki azt mondja hogy "ez csak egy egyszerű LDAP" az még nem látott igazán komplex követelményeket.

Arról nem is beszélve hogy itt az átlag-marika felhasználónak kellene értenie hogy mit csinál és ez az igazi megugorhatatlan probléma.

Gábriel Ákos

A nav elvileg tudja, hogy adott cegnel ki dolgozik. Kene csak egy tovabbdelegalasi lehetoseg, ahol beallitja a főkonyvelo vagy az ugyvezeto, hogy a ceg altal megkapott y jogot z alkalmazott hasznalhatja. 
(kerdes amugy ez hany konyvelot erint, tapasztalatom szerint a legtobb konyvelo one-man-show)

A mobilon való digitális aláírás biztonságosan megvalósítható, ennek a hogyanjára van külön szabvány, amit a magyar törvény is előír. A hozzá kapcsolódó security protection profile elérhető a következő oldalról:

https://www.commoncriteriaportal.org/files/ppfiles/anssi-cc-pp-2018_02f…

Az az 500 ezer ember, akire hivatkoznak, azok lényegében funkcionális analfabéták. Én nem hittem hogy ilyen van, amig ezt nem tapasztaltam. Egy 5 rublikás formanyomtatványt SE tudnak kitölteni. 

Attol, hogy a postit cetlin a jelszavad a te monitorodra van ragasztva, azaz te birtoklod, meg nem jo. Ha a jelszavad masik felet egy kek cetlire firkalod ogorog nyelven, amit a fiokodba teszel, az mar egy picit jobb, de meg mindig nem birtoklas alapu.

Fel lehetne epiteni egy valos, birtoklasos rendszert, de ez igy nem az.

A sved BankId  (itt a bankok toke lett tele az allami benazassal) sem igazi birtoklas alapu, de legalabb managelheto valamennyire a birtokolt hw eszkozok flotaja. Nyilvan megint telefonos es mindnefele PCs szoftverrol beszelunk vegul, tehat kb. halottnak a csok...

 

Ha a totp secret egy hw kulcsban (es a jol vedett allami szerveren) lenne, amelyet a kormanyablakos ugyinezo ad a kezedbe, az lehetne egy valos tobbfaktoros auth. alapja. A totp secretet itt sem szabadna tudnia senkinek, mert onnantol vege.

"állítólag januárban jön egy új feature, hogy email-t is lehet majd 2FA-re használni az Ügyfélkapun."

Előre megyünk nem hátra. Ja, de. (A hardvertokenes (e-személyi) azonosítást kidobjuk, a több példányban is elkészíthető TOTP-t, meg a szintén nem 1:1 megfeleltetést adó e-mailt bevezetjük... (Randomkönyvelő fog egy gmail-es címet, és az ügyfeleknek csinál hozzá alias-t, és azt adja meg a 2. faktorhoz...)

 

Legyünk őszinték, a hardvertokenes azonosításról a felhasználók 99.9%-ának fingja nincs hogy egyáltalán micsoda, szóval itt már projektszervezési kérdés hogy mennyi task van, mennyi erőforrás és melyiknek mi a prioritása.

Az emailes 2FA pedig meg még mindig jobb mint az hogy egyáltalán nem volt 2FA.

Megoldási javaslatom: bitwarden kliens és helyben hostolt vaultwarden. 
Tudja szépen a TOTP-t, szinkronizálja a klienseket, böngészőből is teljes értékűen használható.
Egész cég password kezelését (TOTP-vel együtt) jogosulságokkal, mindennel bele lehet tuszkolni, enterprise cucc.

Gábriel Ákos

Az uzenet sync nem csak ugy hoppa megtortenik, ha mar azt valaki idegen beallitha maganak, tulvagyunk par lepesen amit mind a user tolt el (kitudodott a jelszava, jovahagyta az idegen belepest, jovahagyta a sync bekapcsolasat idegen eszkozre)

Ha a user nem tolna el semmit, annak a több milliárd forintnak csak a töredékét tudták volna meg szerezni, amit (most már) tavaly lenyúltak, csak Magyarországon. Gondolom a szomszédos országokban is hasonló a helyzet.

Néha azaz érzésem, hogy nem csak a szavazáshoz lenne szükség* bevezetni egy alkalmassági teszt kitöltését, de a mobil vásárláshoz** is.

* hogy ne " demagógiával tévesszék meg a szegény" demokratikus választáson részt vevő polgár agyát

**Digitális bankoláshoz, Dáphoz stb.

Cseréld le az ország lakosait az észtekre!

1. Nem fog menni.

2. Még az is lehet akkor szembesülsz azzal, hogy ott is vannak gondok, csak a távolság meg a propaganda megszépíti.

Tehát a feladat: felmérni a célt, a lehetőségeket, mind erőforrás, mind a jelenleg működtetett rendszer(kik fogják használni, kik a legfontosabb felhasználók, milyen eltérő igények vannak) mind a célközönség felkészültsége stb.

Leülni megbeszélni a képviselőkkel, hogy mi az amit mindenképp meg kell csinálni, mi az amiben lehet kompromisszumot kötni, és meghallgatni, hátha vannak segítő ötleteik. Nem biztos, hogy akaratuk ellenére kell megcsinálni, lehet jobb lenne közösen.

Az eredményt nézve ezek közül nem történt meg szinte semmi. Se a DÁP készítő, se a legfontosabb felhasználó (a könyvelők szervezete) nem készült fel arra, hogy a jelenlegi eljárás rendet, hogy kell módosítani, hogy a célt elérjük, anélkül, hogy forradalom törne ki. A haragod, hogy a sok hülye miatt nem elérhető a  szent cél, semmit nem ér. Mint tudjuk harag hatalom nélkül lóf@szt se ér. Persze, ha katonai diktátor lennél, működhetne a dolog úgy ahogy szeretnéd, de hálistennek nem vagy az. Ezért marad -hogy most utólag tűzetoltunk, majd utólag megpróbáljuk megtenni azt, amit előtte kellett volna. De most, hogy így már mindenki "idegbe van", sokkal nehezebb lesz, az idő is szorít, így borítékolható, hogy nagyon pocsék megoldás születik.

Igen. Ezt a "digitális" váltást fel lehetett volna használni arra, hogy a jelenleg működő khmm ... nem szerencsés könyvelő ügymenetet megváltoztassuk, de ez ukázra nem fog menni, a hatalom egy része náluk van, szóval megegyezésre törekvésre lett volna szükség. Én most, hogy mióta ezen a könyvelőzésen rugóztok, pár perc gondolkodás után, például felvetődött, hogy szerencsés dolog -e, hogy egy könyvelőt (és itt pl. azt is észre kellene venni, hogy ez a csapat nem homogén, vannak nagy irodák, aztán kisebbek amik khm .. nem mindig működnek teljesen jogkövetően, meg mancika nénik 10-20 ügyféllel. Szóval lehet, itt is különbséget kellene köztük tenni.) ugyanolyan rendszerrel ellátni, mint pista bácsit, aki csak az évente egyszer* jövő adótervezetét fogadja el benne, s fizeti be az adóját, meg ha nagyon kíváncsi, megnézi az EESZT, vagy egy tervezőt aki rajzokat akar hitelesíteni, hivatalos ügyek intézéséhez, pályázatokhoz heti rendszerességgel.

Szóval az az érzésem, hogy ebben az ügyben, főleg az előkészítés terén, nagyon sokan nem végezték el a dolgukat, s ezzel

1. Eljátszottak egy kínálkozó lehetőséget (talán ezzel okozták a legnagyobb kárt)

2. Komoly mennyiségű pénz égettek el.

3. Az egész digiális ügyintézés és persze kormányzati ügyintés hitelét (azt hogy ez tényleg az emberek érdeke) járatták le.

4. Nagyon sok idő, és plusz munka lesz míg eljut a rendszer oda, ahova már az első alkalommal el lehetett volna jutni, ha tényleg elvégzik a munkát.

Én nem kapálni, én kőbányába küldeném őket, pár hónapra.

Ja, úgy gondolom egyértelmű voltam, de azért itt leszögezem, ez nyilván nem a kóderek, fejlesztők sara, ők már egy kitűzött feladatott oldottak meg.

 

*Jó! Ha háza, autója van 2szer, 3 szor.

Szerkesztve: 2025. 01. 04., szo – 15:35

Linuxon működik a numberstation nevű alkalmazás, most csináltam Ügyfélkapu+ regisztrációt és belépést vele.

Szerk.: Annyit érdemes tudni róla, hogy az elején kéri, hogy valahova és valahogyan tehesse a titkot, amíg azon ügyetlenkedik az ember, a háttérben maga az alkalmazás timeout-ol, és elszáll. Nem elegáns tőle, de semmi jelentősége, amikor már a titkot tudja honnan venni, akkor már jól működik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugyanakkor kérdezem hozzáértőket. Default beállításokat használva 6 számjegyű TOTP-t generál, és 30 s a timeout-ja. Jobban örülnék 1 perces timeout-nak. Újra tudom valahogy ezt csinálni? Úgy értem, vissza tudok oda jutni, hogy az Ügyfélkapu adja nekem a QR-kódot, illetve esetemben karaktersort?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Visszatudni vissza tudsz :)

ugyfelkapu.gov.hu->Ügyfélkapu+ beállítások->Beállítás másik eszközre 

De abból sosem lesz egy perces, azaz a QR kódban az url-t, hogy legyen a végén &period=60 és egyből lesz 60 seces tokened. Az más kérdés, hogy szerintem az ügyfélkapu nem fogja megenni az ellenőrzőkódot. :P

Nekem a numberstation default mondott 30 s timeout-ot és 6 számjegy második faktoros jelszót, és ott van lehetőség állítani a timeout időt is, meg a számjegyek számát is. Ezek szerint ez véletlenül egyezik az IdomSoft implementációjával? Vagy ez egy kvázi szabvány, s a numberstation-t készítették fel az esetlegesen eltérő igényekre?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A túloldaltól függ, hogy mekkora időablakot/hány korábbi/későbbi(!) kódot hajlandó elfogadni, nem a kilens oldaltól. Ha a magyaroszagponthu rfc-szerint megy, akkor te hiába írod át másra nálad, az így generált jód vagy jó lesz, vagy sem (ha kilóg a szerver oldali időablakból, akkor nem lesz jó...)

 

Nyilván nem működne, mivel ezt szerver oldalon is módositani kellene hozzá.

De minek akarnál 1 perces ugrókódot, hiszen - mint fentebb már kifejtettem - a TOTP implementációk elfogadják a +-30 másodperccel eltolódott kódokat is. Tehát nyugodtan beadhatsz az ÜK+ -nak egy 55 mp-e generált, 30 mp-ként ugró (azaz már lejárt) kódot, el fogja fogadni.