AVDH megszűnik

Ha esetleg használtok bármilyen rendszerben AVDH "integrációt", akkor érdemes tudni, hogy a tervek szerint jövőre már nem lesz elérhető. 

A 2024. augusztus 31-én hatályos E-ügyintézési törvény szerinti azonosításra visszavezetett dokumentumhitelesítés-szolgáltatás használatát 2024. december 31-ig kell biztosítani.

https://jogaszvilag.hu/szakma/az-elektronikus-maganokirat-tisztaz-vagy-…

Hozzászólások

Az ügyfélkapu változása is érdekes lesz. A prezentációból:

> AVDH: elektronikus aláírási szolgáltatásként megszűnik (DHSZ megmarad!)
> Ügyfélkapu: hagyományos egyfaktoros azonosítás megszűnik

Digitális állampolgárság Idővonal

k2024 ?     - Végrehajtási rendelet megjelenik
2024.07.01. - Dáp törvény hatályba lép
2024.09.01. - Eüsztv. hatályát veszti
2024.09.01. - DÁP mobilalkalmazás, eAláírás, eAzonosítás
2024.12.31. - Ügyfélkapus azonosítás, AVDH megszűnik
2025.06.01. - Közműszolgáltatókra vonatkozó szabályok életbe lépése
2026.01.01. - ePosta, eDokumentumkezelés, eFizetés

--
Légy derűs, tégy mindent örömmel

Lehet röhögni. Tudom, hogy "kicsit" maximalista vagyok. 😁

Mivel jelszókezelőt használok, így simán megtehetem, hogy eléggé hosszú jelszavakat használjak. Normál esetben legalább 24 karakteres, magas biztonságot igénylő esetben legalább 32 karakteres, kritikus biztonságot igénylő esetben legalább 48 karakteres legyen. Ez a házi policy nálam.

Ez a policy arra is lehetőséget nyújt, hogy a problémás oldalak, webshopok kiderüljenek számomra. A múlt héten például egy magyar, laptopokkal foglalkozó webshop akasztott ki: a kisbetű-nagybetű-szám karaktereken kívül SEMMILYEN MÁS nem lehetett a jelszóban. Ez 2024-ben egy rossz vicc. Ez így gagyi az én mércémmel mérve.

Három karakterosztály bőven elég tud lenni. Az extra írásjel a user által választott jelszavak esetén az írásban  "szokásos" írásjeleket fogja jelenteni (pont, kötőjel, esetleg aláhúzás, néha egyenlőségjel vagy plusz jel), aztán ennyivel ennyi a legtöbb usernél ott, ahol kötelező az írásjel a jelszóba - és ráadásul jellemzően a jelszó végére biggyesztve.
 

Három karakterosztály használatával is készíthető olyan jelszó, ami belátható időn belül rendes hash-t használva nem fejthető vissza. Ha meg a tárolásnál nagyon gyenge a hash, akkor ezen is múlhat inkább, mint a jelszóban használható bájtok halmazának a számosságán.

Kevesebb user supportot. Az emberek az irásjelet felejtik el leggyorsabban a jelszóban, és a "nem tudok belépni" olyan 40%-a az, hogy elfelejtette, hogy a végén van egy pont-kérdőjel-felkiáltójel-elefántsóhaj.

Blog | @hron84

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

via @snq-

No, mégse vagyok én olyan hülye: https://www.hwsw.hu/hirek/68245/jelszo-nist-karakter-hosszusag-ajanlas…

NIST ajánlás: https://pages.nist.gov/800-63-4/sp800-63b.html

"A CSP-knek engedélyezniük kell az akár 64 karakteres jelszó megadásának lehetőségét is, ahogy az ASCII és Unicode karakterek támogatását."

Köszönöm, végre! 🙇‍♂️ 🙇‍♂️ 🙇‍♂️

A PAM döglésének az esetére mit javasolsz? mert ugye ami meg tud dögleni, az meg is döglik... Oké, valami jelszószéf alkalmazás, aminek a jelszavának az n darabját m embertől lehet összeszedni (minden darabot legalább két ember ismer)... Aztán amikor nem tudod kopipaszta a jelszót (mert a jelszószéf program offline/offsite tárolt fájllal dolgozik), ami a fenti hsz-ból a második "a"-betűt tartalmazza, és nem megy a login, akkor lehet agyalni, hogy wtf... Ja, hogy az egy unicode-os ciril kicsi a-betű? Ránézésre nem látszik :-P

A backup visszaállításához is kell jelszó, mert illendően titkosított backup van, nem?

Ha a széf beázik, elvihető, netán nem bírja ki azt a tüzet, ami után még szükség van a tartalmára, az nem széf, nem biztonságos tárolóeszköz. És ugye nem egy, hanem két széf van minimum, nem ugyanabban az épületben, stb...

Ha a széf beázik, elvihető, netán nem bírja ki azt a tüzet, ami után még szükség van a tartalmára, az nem széf, nem biztonságos tárolóeszköz.

Részben nem értek veled egyet. Sajnos a tűz másodlagos hatása (hőhatás) tönkre tudja tenni a digitális adathordozókat. Egyszerűen elolvad a műanyag, tönkremennek a forrasztások. No meg nem mindegy, hogy mekkora tűzről beszélünk és mennyi ideig tart az.

Az sajnos tény, hogy a legtöbb cégnél nem tudnak sem széfet választani, sem elhelyezni azt.
Én meg hiába papolok, hogy nem teszünk széfet gipszkarton válaszfalhoz, padlóhoz rögzítés NÉLKÜL, 1. emeletre, ahonnan közvetlen kilátás van a hátsó udvarra, ami NEM VOLT bekamerázva.

A hőhatás kapcsán írtam azt, hogy "nem bírja ki azt a tüzet, ami után még szükség van a tartalmára" - mellé természetesen az abban elhelyezett adathordozót is jól kell megválasztani, illetve természetesen minimum másik tűzszakaszban, de célszerűen inkább másik telephelyen elhelyezett széfben másolatot is tárolni róla.
 

Nagy kerdes, hogy elmeleti vagy gyakorlati sikon akarjuk megoldani ezt a problemat. Gyakorlati modszerekkel leteznek kulcsrakesz, kiprobalt megoldasok, ezt onnan tudom, hogy en is egy ilyenen dolgozom.

Elmeletileg persze igazad van, mindig lesz egy erosebb flex, egy meg nagyobb foldrenges, egy meg erosebb urleny-hadsereg, egy meg forrobb szupernova, amig az igazan strapabiro rendszereket is egy pillanat alatt meg tudja semmisiteni :)

Emlékeim szerint már régebben is ajánlgattam: Shamir's secret sharing (ugyanaz a Shamir, mint az RSA-beli "S").

Mi azt találtuk ki, hogy a jelszószéf file-t az ország öt különböző pontján tároljuk, és mindegyik mellett ott van a mesterjelszó egy része is. A mesterjelszó visszaállításához az ötből legalább három rész (bármelyik három) szükséges.

Azt szoktam mondani, hogy ha az ország öt különböző pontján tárolt jelszószéf-file és a mesterjelszó ott tárolt része is megsemmisül, akkor már van nagyobb bajunk is ;-)

Kicsit kapkodnak, úgy érzem.  Jelenleg az AVDH *működik*, segítségével tudok ügyet intézni, dokumentumokat beküldeni például egészségpénztárnak, a DÁP meg sehol nincs, a dap.gov.hu arra kér, hogy menjek be a kormányablakba, hogy várólistára kerülhessek.  End userként kb. nem érdekes, hogy technológiailag mekkora tákolmány az AVDH, akkor kellene kiváltani, ha már van bejáratott, működő alternatíva.

Én hiába tudok S/MIME aláírt emailt küldeni vagy akár pl. a Docusign nevű rettenetet használni, ha a fogadó oldal kifejezetten AVDH-t szeretne és más fogadására/ellenőrzésére az ottani munkaerő fel sincs készítve.  És visszakanyarodva az eredeti hozzászólásomhoz, arra próbáltam kilyukadni, hogy mivel nem elérhető még széles körben az utódjául szánt szolgáltatás, a tervezett év végi kivezetést meglehetősen korainak tartom.

Nezd meg a planoknal a feature listat, az osszes publikus csomag a “simple”t tudja csak. Ami nem szamit elektronikus alairasnak, technikai ertelemben, az az a szint amikor wordbe odairod a neved vagy beilleszted az alairasod egy kepbol.

sajat maguk is leirjak:

If ID verification is needed, an advanced or qualified electronic signature may be required

rendes megoldas csak custom/enterprise csomagban van plusz penzert

A valós digitális aláírást biztosító, auditált rendszerekben a regisztráció során történik egy személy azonosítás (sok helyen ezért kell fizikailag is bemenni) majd pedig létrehoznak egy privát kulcsot egy HSM-ben, valamint beállítják a hozzáférését a felhasználónak az adott kulcshoz (két faktorosat). Innentől a felhasználó feladata ennek a védelme mert ezek az aláírások a bíróság előtt olyannak felelnek meg, mintha 2 tanú előtt történt volna meg az aláírás. Ezért vannak rommá auditálva ezek a bizalmi szolgáltatók.  

"a minősített elektronikus aláírás a saját kezű aláírással azonos joghatású, azaz ezzel más személyek „segítsége”, tanúk, ügyvéd vagy közjegyző nélkül is létrehozható olyan dokumentum, ami teljes bizonyító erővel bír, azaz az ellenkező bizonyításáig az egész EU területén teljes bizonyító erővel bizonyítja, hogy az okirat aláírója az abban foglalt nyilatkozatot megtette, illetve elfogadta vagy magára kötelezőnek ismerte el."

https://jogaszvilag.hu/szakma/digitalis-vs-elektronikus-alairas/

Ezért kell baromira védeni a digitális aláíráshoz szükséges hozzáférést, mert bizony el lehet adni az autóját valakinek teljesen törvényesen ha nem vigyáz az azonosításhoz szükséges dolgaira.
 

Nem ez az első hülye rendelkezés a világon, de van az a lobbi ami átnyomta.
Technikai szempontból nem változik semmi: a digitális aláírás azt bizonyítja hogy XY kulcsához volt hozzáférés, nem pedig azt hogy XY aláírta.
És persze: a felhasználó hibája ha ellopják az adatait, nem a rendszer rossz.

Az AVDH valóban baromság volt úgy,ahogy itt ment: user bejelentkezett usernév/jelszó párossal, és utána kapott a dokumentumára egy stemplit, hogy az AVDH-s aláíró azonosította és ő az, akinek mondja magát. Azonosította. Akár egy usernévvel meg egy jelszóval.
Az e-személyi az ennél fényévekkel jobb megoldás (volt), mivel ott egy célhardver birtoklása, és az azon lévő érvényes(!) certhez tartozó privát kulcs feloldásához szükséges, kötelezően x számjegyből álló PIN ismerete (volt) szükséges az aláíráshoz. Ez a módszer jelenleg is működik üzleti szolgáltatásként, csak épp egy QSCD eszköz kb. nettó 20E Ft körül van, és erre még kell a megfelelő szintű tanúsítvány is (jellemzően a kártya/token cert igénylésével együtt olcsóbb), de nem ördögtől való a birtoklás+tudás alapján elkészített, teljes bizonyító erejű magánokiratot biztosító elektronikus aláírás. Mivel a telefonból a privát kulcsot ugyanúgy nem tudod kinyerni, _és_ az eID-hez megkövetelték vagy a személyes azonosítást, vagy az NFC-s e-személyis azonosítást (személyi+pin), így az aláíráshoz szükséges kulcspár/cert elkészülte és telefonba költözése sem ördögtől való.

Az AVDH az volt, mint amit a neve is elárul: Azonosításra Visszavezetett Dokumentum Hitelesítés.
Az E-személyis aláírás tényleg jobb volt, de az meg már nincsen.
A DÁP meg nem megy megfelelő okostelefon nélkül. Szóval egy számítógéppel már nem használható semmire sem.

Érdekel, hogy így januárban hogy lehet majd ügyet intézni.

Nagy Péter

Hát, pontosan ez a gondom! A Digitális Állampolgárság nevű kezdeményezés azt eredményezi, hogy amit eddig ingyen és kényelmesen el tudtam intézni számítógépről, ahhoz most vagy be kell mennem, és papíron intézni, vagy tanúsítványt kell vennem pénzért (amihez szintén személyesen kell azonosítanom magam egy tanúsítvány-kiállítónál), és azzal intézni.

Nem érzem magam tőle Digitálisabbnak. 

Nagy Péter

És persze itt is felmerül az a kérdés, hogy ha a fogadó fél kifejezetten DÁP aláírást vár el, akkor kitörölheted a seggedet a digitális tanusítványoddal a _valamelyik_ kiadó cégtől.

Nem kell emlékeztetnem senkit ugyebár, hogy itthon még mindig csak a Netlock számít sok helyen elismert hitelesítésszolgáltatónak _kizárólag_.

Blog | @hron84

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

via @snq-

Az egészben a legviccesebb, hogy az AVDH megszűnésének pillanattától pont előírták, hogy az ügyfélkapu eléréséhez kötelező a két faktoros ügyfélkapu+, vagy a DÁP használata. (az e-személyi-s bejelentkezést pedig attól a pillanattól vezetik ki éppen)

Nagy Péter

1 faktoros authentikacioval, Juliska123! jelszó mellett egyébként is megkerdojelezheto a hitelesség. 

Error: nmcli terminated by signal Félbeszakítás (2)

Erre _sem_ lett volna szabad használni, mivel egy usernév/jelszó párossal teljes egészében megszemélyesíthető az adott állampolgár úgy, hogy annak, amit így tesz a támadó az adott polgár viseli az összes jogkövetkezményét - de elég, ha az összes adatát, ami üf.kapun keresztül elérhető leszipkázzák...

Mondjuk úgy, hogy az qrvarégen volt, hogy a usernév/jelszó elégségesnek tekinthető volt - az igazi gond a 2FA kiterjesztésével/kötelezővé tételével az volt, hogy az n+1 ügyfélkapu alá integrált rendszerben nem voltak képesek mindenütt megvalósítani az ügyfélkapu+ kompatibilis működést...

Nem jól érted. Korábban nekem a Lechner tudásközpontnál lévő szolgáltatásokhoz nem működött az ügyfélkapu+ (az érdeklődésemre válaszul azt írták, hogy dolgoznak rajta - legalább fél évvel voltunk az ügyfékapu+ bevezetése/élesítése után egyébként...) de tippre azért bátorkodnak betervezni a 2FA kötelezővé tételét (vagy ugye az e-személyis logint), mert addigra minden érintett/kapcsolódó rendszer képes lesz ezt kezelni.
 

Az faca, egy durva nagy visszalépés, mert ugye ToTP-t kávédarálón is lehet futtatni minden biztonsági körítés nélkül, egy hardvertokenes cert alapú login ennél sokkal biztonságosabb, hiszen a birtoklás az egy és csak egy eszközhöz köti a logint, nem egy szoftveresen simán másolhatóhoz. (Kereshetem elő a üfkapu+ usernév/jelszó párost - szerencsére a GA-ban minimum két telefonon ott van a 2. faktorhoz a secret...)
 

Az ügyfélkapu+ jelenleg is GA-val vagy MS Authenticator-ral, szabványos TOTP-vel működik, mindkettő képes a kódokat (azaz azokat a shared secret-eket, ami alapján generálható az idő alapú kód) google, illetve microsoft fiókba menteni... És onnan sima liba kihúzni egy másik eszközre az összeset egyben, de GA-ból egy saját formátumú QR-kóddal is átvihető egy másik GA instance-ba. Ez lesz ahelyett, hogy egy kizárólag egy példányben létező hardvertokenen tárolt, onnan ki nem nyerhető kulcsot használna azonosításra az ügyfélkapu... (hogy ez e-személyi, vagy valamilyen más, X509-es certet használó megoldás, jelen esetben mindegy.)
 

Annyit még hozzátennék, hogy TOTP-t pl. KeePass is tud kezelni (pluginnal még jobban), és a GA-ból a QR kóddal exportált tokeneket a KeePass alá is be lehet olvasni (vagy fordítva is, lehet exportálni is). A KeePass pedig utána kiír minden secretet, ami csak érdekel, akár QR kódot is mutat hozzá.

Nagy Péter

A tokennel az a baj, hogy ahhoz minimum driver kell a géphez, és telefonról például mérsékelten lesz üzemképes, mert nem tudod hova bedugni, stb.

Sajnos hiába az a legbiztonságosabb megoldás, az r=0.5 felhasználókkal inkompatibilis. Még a TOTP azonosítás is rengeteg helyen billeg, nagyon komoly mennyiségű felhasználó támogatás fog kelleni a használatához, de azt jelenleg beláthatóbbnak gondolom (mert jobban el is van terjedve) mint egy token alapú cuccot.

Blog | @hron84

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

via @snq-

Az e-személyi tökéletes eszköz lett volna, ahogy az eID-re történő, qrmányablakba befáradás nélküli regisztrálás is működik. Vagy ahogy az eszemélyihez készült app is, ami egy sima kártyaolvasót csinál a telefonból, amivel az eszig PC-s alkalmazás hálózaton beszélget...

 

Az okostelefonbuzi mivolta miatt, a Google/Apple-függősége miatt és amiatt, mert jól működő okostelefonok százezreit kell kidobálni, az Android 10 és iOS 16 minimum OS-követelményeknek köszönhetően. Mindeközben biometrikus azonosítás már Android 5.0-án is van.

Nem a biometrikus azonosítás hiánya a probléma, hanem az, hogy a régi android-okban rengeteg olyan hiba, sérülékenység van,a mit de facto már nem fognak javítani. Egy security device lukas, gyártói supporttal nem rendelkező szoftverrel nem security device, hanem e-hulladék, akár tetszik, akár nem. Nem kell a régi telefont kidobni, csak épp biztonsági eszköznek, illetve elektronikus okmánynak nem lehet azokat használni.
 

Nem kell a régi telefont kidobni, csak épp biztonsági eszköznek, illetve elektronikus okmánynak nem lehet azokat használni.

Lehet őket használni, biztonságtudatosan, pont úgy, mint egy Windows XP-t, a támadási felületeket minimalizálva. iOS esetben pedig nem is igaz, amit írsz, mert biztonsági javításokat szokott kapni.

Szerkesztve: 2024. 09. 01., v – 20:02

Aki pedig nem rendelkezik kétévente újravásárolt okostelefonnal, az visszatérhet a papíralapú ügyintézéshez, aláíráshoz, ugyanis már induláskor Android 11 az igénye az IdomSoft Zrt. babzsákfejlesztői által összetákolt Digitális Állampolgár csinálmánynak.

Ismét jól működő rendszerek tönkretételével akarunk fejlődni™.

AVDH egy csökevény volt

Ezt nem vitatja senki.

Az új megoldással el fogom tudni intézni az állami (egészségpénztári, stb) dolgaimat a desktop Fedorámról vagy hozzáköt valami szűk platformhoz, mert csak? Ha hozzáköt, akkor per definition funkciót vesztek el, ami zavar. 

Az appot nem én fejlesztem, de ahogy sejtem a telefont fogja használni aláíró eszközként (mint szinte minden ilyen). Ami teljesen rendben van. Nem hinném, hogy a te desktopodat fel kellene adnod emiatt, csak épp kell egy (meglévő) eszköz majd az aláírás elfogadására. Ha nem így csinálják meg, akkor Viktornál panaszkodj. 

Van ügyfélkapud? Van. Abból tessék ügyfékapu+ -ra váltani. Mivel a QR-kód tartalma jól definiált,a mit a 2FA beállításához kapsz, azzal akár egy konzolos totp-alpkalmazást is meg tudsz etetni, és onnantól kezdve készen is vagy.

Egyébként meg lehet venni kártyaolvasót nem túl súlyos pénzekért, és azzal, meg az e-személyiddel (és a megfelelő alkalmazással) alá tudsz írni, be tudsz jelentkezni az ügyfélkapu-n.

Hogy egy rolling disztribúcióban ezek mennyire működőképesek, azt nem tudom, de a szolgáltatásokat jellemzően a felhasználói bázis eloszlása alapján a nagy többségre alakítják ki.

Van ügyfélkapud? Van. Abból tessék ügyfékapu+ -ra váltani.

what? Ez hogy jön ahhoz, hogy kivezetik az AVDH-t, és, ha jól értem a szálat, a helyette jövő DÁP nem lesz elérhető desktopon?

(régesrég 2FA-s az ügyfélkapum, ne is beszéljünk róla, mekkora szar megvalósításban)

Szerintem Polgárjenő vagy ASP-s iktatórendszerrel ír alá (az is ilyen AVDH szerű hozzácsapja PDF-be mellékletként ki írta alá, majd a rendszer aláírja), vagy a NISZ-es GOVCA-s PKI-s mókolással, hisz az esziges aláírásából nemigazán derül ki, hogy ő polgármesterként írta alá. 

A cikkből:

... januártól már csak e-aláírással lehet ügyvédi meghatalmazást adni az ingatlanos ügyintézésekhez. Az eSzemélyihez kapcsolt aláírás azonban a lakosság 98 százalékánál nincs meg, és az AVDH sem lesz már használható ...

Az ütemtervük szerint a DÁP mobilalkalmazás, eAláírás, eAzonosítás 09.01-től elérhető és úgy néz ki január 1-től megkerülhetetlen. Mintha most lenne teszt üzem jövőre pedig éles üzem...
--
Légy derűs, tégy mindent örömmel!

Azért jó az AVDH, mert működik, platform-független és tetszőleges dokumentum aláírható vele. Emellett PDF-be is képes beágyazni az aláírást. Ha a Digitális Állampolgárság fronton is születik egy ilyen megoldás, akkor az is megfelelő lesz az AVDH helyett. Ha nem születik, akkor az visszalépés lesz az AVDH-hoz képest, akkor is, ha az AVDH most egyesek szerint nem tökéletes.

1. Irreleváns, amennyiben magyarországi ügyintézésről van szó.

2. A felhasználó és a rendszer által van aláírva, pontosabban a rendszer által, a felhasználó nevében.

3. Semmivel sem szarabb, mint egy okostelefonos szutyok, ami még a kétfaktoros hitelesítés koncepcióját sem teljesíti, ha minden az okostelefonon történik.

és milyen igazad van. Nem ettől. Hanem ettől lesz igazam:

2. A felhasználó és a rendszer által van aláírva, pontosabban a rendszer által, a felhasználó nevében.

Ez mi? Érted mi az az elektronikus aláírás? Vagy csak megerősíted, hogy igazam van és ilyen formában helyeselsz?

3. Semmivel sem szarabb, mint egy okostelefonos szutyok, ami még a kétfaktoros hitelesítés koncepcióját sem teljesíti, ha minden az okostelefonon történik.

Miről beszélsz? Tudod hogy fog működni?

Ez mi? Érted mi az az elektronikus aláírás? Vagy csak megerősíted, hogy igazam van és ilyen formában helyeselsz?

Te érted, hogy az elektronikus aláírás mitől lesz hiteles? Nem attól, hogy én generálok egy random kulcsot és azzal aláírok valamit. Hanem attól, hogy azt a Belügyminisztérium is hitelesnek ismeri el és ez a hitelesség bármikor ellenőrizhető. Ha az aláírás az én gépemen történik, nem az Ügyfélkapu szerverein, ugyanúgy szükségem van hitelesített kulcsra, amit a Belügyminisztérium is hitelesnek tekint. Ezt felfogod? Ha igen, akkor innentől már csak egy lépésre van az, hogy kb. mindegy, kinek a gépén történik az aláírás. A lényeg, hogy kinek a megbízásából.

Miről beszélsz? Tudod hogy fog működni?

Pontosan úgy, ahogy az összes többi "kétfaktoros" app, ami megelégszik azzal, hogy az egyik faktor az okostelefon, meg a másik faktor is az okostelefon.

Tehát, nem, megint nincs igazad, csak igyekszel erőltetni a csőlátásod azzal, hogy másokat leminősítgetsz.

Nem érted a pki "lényegét" és ilyen "apróságokat" elfelejtesz, hogy mindketten egy harmadik (megbízható) entitásban - a tanúsítóban bíztok meg - ill. hogy a privát kulcsod a te birtokodban van jó esetben egy biztonságos tároló eszközön és azt nem hagyja el soha, ezért más a te "nevedben" aláírást nem tud készíteni.

Sajnos hajbazernek abban igaza van, hogy ha egy azonosítás mindkét faktora elvégezhető ugyanazon az okostelefonon (weboldalon bejelentkezés, plusz appban hitelesítés), akkor tökmindegy, hogy a mobilappba ki adta ki a tanúsítványt, és az sem segít, ha a tanúsítvány telepítése netán az okmányirodában történt, személyes azonosítás után.

Hajbazernek abban nincs igaza, hogy ez a megoldás olyan, mint a jelenlegi AVDH. Nem olyan, mert illetéktelen behatolónak előbb fizikailag hozzá kell férni az eszközhöz. Ez azért mégsem ugyanaz a szint, mint ha nekiállnék az Ügyfélkapuban próbálgatni a neveket, jelszavakat. 

Ha úgy csinálják meg ahogy kell, akkor valószínűleg összeraktak egy teljes cert. rendszert a háttérben, azaz van egy SSA, van egy SAM, illetve van egy HSM amelybe legenerálódnak a privát kulcsok de ezt kívülről nem lehet kinyerni hanem csak aláírásra használni. A HSM előtti dobozok feladata a kulcshoz való hozzáférést korlátozni: azt biztosítani, hogy mindenki csak a saját kulcsához fér hozzá és azzal csinál aláírást. Ha minősített aláírást akarnak, akkor ehhez szükséges a 2 faktor (ha jól emlékszem a SAM-hez tartozó CC PP-ben vannak a követelmények, de ez kihivatkozik az EN 419 241-1, ahol leírja hogy ezt hogyan kell), mindenesetre itt van a kapcsolódó PP:

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

Az aláírás során a dokumentumból képződik egy hash, ehhez hozzácsapják az auth információt, meg hogy melyik kulccsal szeretnénk aláírni, átmegy az SSA-SAM-be, ott megtörténik az ellenőrzés, a privát kulcsot aktiválják, ezzel aláírják a hash-t, majd az aláírás plusz a cert bekerül a PDF-be. Hogy a komplett dokumentum elküldésre kerül-e és ők csinálják meg a csomagolást vagy hogy ez a kliens oldalon történik-e, ez egy jó kérdés. 

De a lényeg: ahhoz hogy ez a folyamat végigmenjen tehát szükséges a 2 faktor megadása, ez általában egy felhasználónév/jelszó illetve egy TOTP kód lesz. Ez igy együtt fogja engedélyezni az aláírást. 
 

Az állam megengedte magának hogy bízzon benned (meg te is benne), hogy helyetted készít aláírást - ha előzőleg azonosított elégséges módon. Ennek viszonylag kevés köze van ahhoz, hogy technikailag mi lenne a megbízható vagy hol kéne még a világban megbízható aláírást készíteni tudni.

(Ha jól tudom személyit is lehet úgy pótolni, hogy nem változik a privát kulcsod... Az kit zavar? ;) )

Nem szükséges. Nem fog lerohadni a lábam, ha be kell mennem a kormányablakhoz személyesen, ügyet intézni.

Inkább sajnáld azt az Isten tudja mennyi okostelefont, amit emiatt fognak újravásárolni, kidobni.

Sajnáld a privát szféráját azoknak, akiknek ezentúl muszáj lesz eladniuk a lelküket minimum az Apple-nek vagy a Google-nek, hogy élhessenek a Digitális Állampolgárság lehetőségével.

Nem kell semmit sem kidobni. Az e-személyihez kell egy megfelelő kártyaolvasó, amit akár az eSzemélyiM alkalmazással is ki lehet váltani, ha minden igaz.

Az, hogy a személyazonosításra használt okmány vagy elektronikus eszköz milyen biztonsági feltételeket kell, hogy teljesítsen, azt szerencsére nem te határozod meg - ha nem tetszik, nincs megfelelő eszközöd, akkor nem kell használni.

Az, hogy a személyazonosításra használt okmány vagy elektronikus eszköz milyen biztonsági feltételeket kell, hogy teljesítsen, azt szerencsére nem te határozod meg - ha nem tetszik, nincs megfelelő eszközöd, akkor nem kell használni.

  1. Biometrikus azonosítás már Android 5.0-án is van. Nem biztonságról beszélünk itt, hanem az IdomSoft babzsákfejlesztők kényelmeskedéséről.
  2. Egy eszköz annyira biztonságos, amennyire a felhasználója biztonságtudatos.
  3. Nem azzal szokott probléma lenni, hogy egy alkalmazás megkövetel bizonyos biztonsági feltételeket, saját magára nézve. Azzal van, amikor a felhasználói szabadságot tiporja sárba azzal, hogy márpedig mindenhez is, az okostelefonon globálisan szükség™ van™ ujjlenyomattal nyitható lock screen-re, nem csak magához az alkalmazáshoz, ahogy egyébként értelmes és logikus lenne.

Már a 6-os android, mint minimum (API level 23) is warning-ot generál a google store-ba töltött alkalmazásnál, és a tervek szerint hamarosan a "nem frissíthető" kategóriába kerülnek azok az alkalmazások, amik ezt a minimumot adják meg. Ami meg ennél régebbi minimumot igényel, az már most sem megy át a Google élesítési validáción. Szóval hiába is akartak volna 21 vagy 22 API-szintet adni minimumnak, a Google nem fogadta volna be az alkalmazást.

"Egy eszköz annyira biztonságos, amennyire a felhasználója biztonságtudatos."

Ha hálózat felől, alkalmazásokon keresztül törhető, akkor nem adok neki hálózatot soha, mert biztonságtudatos vagyok... Csak épp jelen esetben pont kell neki hálózat...

Az eszköz feloldása és az alkalmazáson belüli azonosítás nagyon nem ugyanaz a réteg, nem ugyanaz a funkció. Használsz jelszót a windows-on? Minek, mikor az összes webes alkalmazásban, amit nyomogatsz róla, van jelszó...
 

Szóval hiába is akartak volna 21 vagy 22 API-szintet adni minimumnak, a Google nem fogadta volna be az alkalmazást.

Akkor lehetett volna Android 7 a minimum.

Az eszköz feloldása és az alkalmazáson belüli azonosítás nagyon nem ugyanaz a réteg, nem ugyanaz a funkció.

Én is ugyanezt mondtam. Az ilyen biztonságos™ alkalmazások mégis kikényszerítik, hogy legyen lock screen.

Captain Obvious Stirkes Again.

Attól, hogy értelmező szótárt játszol, még nem lesz szükséges a lock screen egy olyan alkalmazásnak, amit lehetne egymagában is védeni ujjlenyomat bekérésével úgy, hogy a többi appot békénhagyjuk (a felhasználó belátására bízzuk) az által, hogy nem rakunk kötelezően lock screen-t.

Nem kell ilyen appot mutatnom, ugyanis számtalan olyan app van, ami a kritikusabb műveletek elvégzése előtt is kérnek azonosítást, pl. Apple FaceID-t. Ilyen alapon nyugodtan lehetne bekérni az ujjlenyomatot az e-személyi appban.

Nem beszélve arról, hogy a lock screen-nek is van timeoutja, tehát ha a felhasználó nem zárja le a telefonját, az ugyanaz a kategória, mint amikor nem lép ki a NetBankból, vagy nem zárja be az ujjlenyomattal indított e-személyi appot.

Valaki esetleg használja az eszemélyi-s ügyfélkapu belépést linux alatt? Neten nem sok infót találtam róla...

Persze, de azért mondjuk egy parancssoros TOTP referenciaimplementációval nem biztos, hogy egyszerű lesz :-) És itt is van a hátulütője, illetve a visszalépés a hardvertokenes (e-személyi) azonosításhoz képest: az azonosításra szolgáló eszköz illetve információ tetszőleges számban észrevétlenül másolható, ellopható.

Naszoval. Ugyfelkapu+ igenylese soran ott a QR kod, de el lehet kerni tole a TOTP secretet is. Ez mehet az oathtool-nak, es boldogsag.

Igy nem kell mindenfelet jottment telefonos auth applikaciora bizni a titkaimat. Mehet a kod egy jelszo adatmazisba, AES256 titkositott fileba, szep sarga Post-it papirosra a monitor szelere stb.

Nagyon nem tudja arrafelé senki, hogy hogy működik ez...? Mert nekem kifejezetten úgy tűnik... A TOTP esetén a secret (gy.k. "titok") az ott van mindkét oldalon, és abból meg a pontos időből készül publikus algoritmussal egy numerikus kód. Ha a secret-et elviszi valaki, akkor onnantól kezdve b/6-ja a 2FA-t, mert aki elvitte, az is tud 2. faktorhoz kódot generálni...

 

Én is ezt mondom, hogy ez egy olyan előrelépés, ami hátrafelé történik... Ennél még az e-személyin lévő cert alapján történő login is jobb lenne... És az sem egy űrtechnolóia...

Én a "sima" ügyfélkapuróla hogy kitolták az ügyfélkapu+ -t, váltottam, illetve amikor az első e-személyit megkapta, akkor vettem egy kártyaolvasót, és inkább azt használtam bejelentkezésre - mert a három közül azt tartom a leginkább biztonságosnak. Erre most vissza..asznak a usernév-jelszó-tetszőlegesen sokszorosítható TOTP használatára, mert az e-személyis fejlesztésből... már nem lehet több gempát kiszedni...
Mondjuk ha az eID-s azonosítás úgy fog működni, hogy qr-kód, amit az eID beolvas, és másik csatornán beküldi, hogy "oké, mehet", akkor az jó is lehet - csak ugye ehhez média, illetve kamera jog kell az alkalmazásnak...

"Mondjuk ha az eID-s azonosítás úgy fog működni, hogy qr-kód, amit az eID beolvas, és másik csatornán beküldi, hogy "oké, mehet", akkor az jó is lehet - csak ugye ehhez média, illetve kamera jog kell az alkalmazásnak..."

ez nem olyan, mint az otp qr kodos belepese?

neked aztan fura humorod van...

Egyébként is tönkreteszi valid pdf/A3 -at:
verapdf avdhA3-ff846980-c6b4-48b6-8f55-62b479775289.pdf

<?xml version="1.0" encoding="utf-8"?>
<report>
  <buildInformation>
    <releaseDetails id="core" version="1.26.1" buildDate="2024-05-16T16:30:00+02:00"></releaseDetails>
    <releaseDetails id="validation-model" version="1.26.1" buildDate="2024-05-16T18:13:00+02:00"></releaseDetails>
    <releaseDetails id="gui" version="1.26.2" buildDate="2024-05-19T13:33:00+02:00"></releaseDetails>
  </buildInformation>
  <jobs>
    <job>
      <item size="1206764">
        <name>/home/zolti/Downloads/avdhA3-ff846980-c6b4-48b6-8f55-62b479775289.pdf</name>
      </item>
      <validationReport jobEndStatus="normal" profileName="PDF/A-3B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false">
        <details passedRules="141" failedRules="4" passedChecks="7020" failedChecks="9">
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="3" status="failed" failedChecks="2">
            <description>The file specification dictionary shall contain key AFRelationship of type Name identifying the relationship between the embedded file and the content of the document</description>
            <object>CosFileSpecification</object>
            <test>AFRelationship != null</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]</context>
              <errorMessage>The file specification dictionary for an embedded file does not contain the AFRelationship key or it has invalid value type</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]</context>
              <errorMessage>The file specification dictionary for an embedded file does not contain the AFRelationship key or it has invalid value type</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="4" status="failed" failedChecks="2">
            <description>The additional information provided for associated files as well as the usage requirements for associated files indicate the relationship between the embedded file and the PDF document or the part of the PDF document with which it is associated</description>
            <object>CosFileSpecification</object>
            <test>isAssociatedFile == true</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]</context>
              <errorMessage>The file specification dictionary for an embedded file is not associated with the PDF document or any of its parts</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]</context>
              <errorMessage>The file specification dictionary for an embedded file is not associated with the PDF document or any of its parts</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="1" status="failed" failedChecks="4">
            <description>The MIME type of an embedded file, or a subset of a file, shall be specified using the Subtype key of the file specification dictionary. If the MIME type is not known, the "application/octet-stream" shall be used</description>
            <object>EmbeddedFile</object>
            <test>Subtype != null &amp;&amp; /^[-\w+\.]+\/[-\w+\.]+$/.test(Subtype)</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]/EF[0]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/EmbeddedFiles[0]/EF[1]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]/EF[0]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]/EF[1]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.2.11.4.2" testNumber="2" status="failed" failedChecks="1">
            <description>If the FontDescriptor dictionary of an embedded CID font contains a CIDSet stream, then it shall identify all CIDs which are present in the font program, regardless of whether a CID in the font is referenced or used by the PDF or not</description>
            <object>PDCIDFont</object>
            <test>fontFile_size == 0 || fontName.search(/[A-Z]{6}\+/) != 0 || containsCIDSet == false || cidSetListsAllGlyphs == true</test>
            <check status="failed">
              <context>root/document[0]/pages[0](4 0 obj PDPage)/annots[0](85 0 obj PDWidgetAnnot)/appearance[0]/contentStream[0](81 0 obj PDContentStream)/operators[2]/xObject[0]/contentStream[0](78 0 obj PDContentStream)/operators[6]/xObject[0]/contentStream[0](74 0 obj PDContentStream)/operators[4]/font[0](AAAAAB+Roboto-Regular)/DescendantFonts[0](AAAAAB+Roboto-Regular)</context>
              <errorMessage>A CIDSet entry in the Font descriptor does not correctly identify all glyphs present in the embedded font subset</errorMessage>
            </check>
          </rule>
        </details>
      </validationReport>
      <duration start="1725721286833" finish="1725721287583">00:00:00.750</duration>
    </job>
  </jobs>
  <batchSummary totalJobs="1" failedToParse="0" encrypted="0" outOfMemory="0" veraExceptions="0">
    <validationReports compliant="0" nonCompliant="1" failedJobs="0">1</validationReports>
    <featureReports failedJobs="0">0</featureReports>
    <repairReports failedJobs="0">0</repairReports>
    <duration start="1725721286756" finish="1725721287608">00:00:00.852</duration>
  </batchSummary>
</report>
Szerkesztve: 2024. 10. 04., p – 12:21

Az egész eIDAS találmány egy katasztrófa (mivel a gyakorlatban drága és körülményes, nincsen elég szolgáltató megfizethető áron és platformfüggetlenül, aki megfelel az eIDAS-nak), csak akkor használjon valaki elektronikus aláírást, ha kötelező, egyébként jobb a papír alapú. Amit sokan elfelejtenek, hogy nem elég valamit elektronikusan aláírni, hanem azt utána elektronikusan archiválni is kell, minősített elektronikus archiváló szolgáltatással, különben idővel lehetséges, hogy a már aláírt dokumentum elveszíti a hitelességét.

Gyakorlatilag 2 db ilyen archiváló szolgáltató van, ebből az egyik a Netlock volt amit éppen most szüntette meg teljesen az elektronikus archiválást! Nem viccelek. Elektronikus aláírást adnak, de az archiválást már oldd meg, ahogy tudod... Van a Microsec archiválás és nagyjából ennyi, mást nem is tudok.

Nem, az archiválás nem azt jelenti, hogy fellövöm felhőbe, ennél sokkal bonyolultabb.

Akkor tudna terjedni az elektronikus aláírás, ha az állam biztosítana legalább magánszemélyeknek ingyenes elektronikus aláírást, időbélyeget ÉS minősített elektronikus archiválást is, ami mind eIDAS-kompatibilis lenne, ez tudná kiváltani a papír alapú ügyintézést. Az archiválás hiányában én semmit sem írnék alá elektronikusan, hiszen idővel a már aláírt dokumentum elveszítheti a hitelességét, és akkor olyan mintha nem is létezne. Csak az archiválás biztosítja hogy hosszú távon is megőrzi a dokumentum a hitelességét, de amíg az állam nem ad ilyet ingyen, addig sokkal jobb papír alapon aláírni. (Most magánszemélyként / kkv-ként értem, nyilván ha naponta keletkezik több ezer aláírandó dokumentum, az más kategória.)

Azt értettem, de - naívan - azt gondoltam, hogy ezeket a kormány is aláírja diigtálisan... Na mindegy.

Érdekes dolog ez az elektronikus aláírás, én is még csak piszkálgatom a témát, mert szerencsére a mindennapokban _még_ semmi szükségem rá, csak nem akarok hülyén meghalni. Én hiszek abban, hogy ha majd szélesebb körben lesz rá szükség, lesz az archiválásra is valamilyen megoldás, akár itthon, akár az EU-ban. De ez kettős dolog: egyelőre a legtöbb szolgáltató/merchant is a papíros dolgokban hisz, pedig cégként biztosan egyszerűbb lenne a digitális. 

Blog | @hron84

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

via @snq-

Az eIDAS egy nagyon erős szabályozás, mert egy minősített elektronikus aláírással aláírt dokumentum teljes bizonyító erővel bír. Ez egy nagyon nagyon erős vélelem, és ezért nagyon magas szintre van rakva a biztonság: egy tanúsítványkiadó cégnek elképesztően sok szabályozásnak kell megfelelni mind IT biztonság, mind folyamatok szintjén, ráadásul folyamatosan auditálják őket, mind a szoftvereket mind pedig a működést/folyamatokat. Ez egy nagyon nehéz domain, folyamatosan tanulni és képezni kell a dolgozókat mert csak igy tartható fenn egy bizalmi szolgáltató működése. Az eszközök pedig folyamatosan avulnak, a szoftvereket pedig fejleszteni kell.

Ehhez képest valójában nem drága, havi durván 5 ezer forint + áfa körül van mindkét cégnél egy minősített tanúsítvány, cserébe az irodádból el tudsz mindent intézni. Hogy ez valakinek megéri-e, vagy sem, ez egy jó kérdés, ki kell számolni.

Az archiválást valószínűleg azért szüntette meg a Netlock mert amennyibe az valójában kerülne, annyit nem hajlandó érte senki fizetni, a felülbélyegzés egyébként még csak-csak megoldható, de a végtelen ideig tárolás úgy, hogy az tutira meglegyen... hát, nem egyszerű. Egyébként van olyan cég, amely ad is erre megoldást:

https://www.digitdoc.hu/megoldasaink/hosszu-tavu-archivalas

Archiválásra egyébként 5+ illetve 11+ év esetén érdekes, a legtöbb kézzel aláírt dokumentumot valójában már 5 év után selejtezik.

Az elektronikus aláírással alapvetően szerintem nincs gond, ha bejön ez az új mobilos megoldás azzal egy átlag ember a használati eseteinek a 95%-át le tudja fedni, a maradék 5% esetén pedig majd szépen kézzel aláír, a cégeknek meg letöbbször tömeges aláírásra van szükség, azt pedig most is megoldják.

 

De az milyen már hogy elektronikus aláírás archiválási szolgáltatás nélkül? Pont ez a baj az elektronikus aláírással, hogy kell mellé archiválás is, az meg te is írod olyan bonyolult és drága, hogy nem akar vele senki bajlódni. Tehát a gyakorlatban jelenleg az eIDAS nemigazán működik. Kellene sokkal több cég aki kínál megfizethető áron elektronikus aláírást, időbélyeget ÉS archiválást egyszerre, vagy ha ez nem megy, akkor az állam adjon ingyen, hogy terjedjen a digitalizáció. El tudom képzelni hogy megérné, ha az állam adná ingyen mindenkinek, ha ezzel nőne a GDP (pl. sok időt spórolna mindenki amit produktív, termelő munkára fordíthatna).

Érdekes lenne megnézni, hogy az USA-ban hogy működik ez ez elektronikus aláírás dolog, valahogy csak eldöcögnek ott milliárd dolláros cégek.

De érted, az a baj, hogy a magyar piac csórókból áll, itt még az is meglepő hogy van egyáltalán két épkézláb cég amely digitális aláírással foglalkozik, eiDAS-t rendesen betartva (jó, három, mert ott a NISZ is). Mindenki azt hiszi hogy ez mekkora egy atom biznisz, pedig valójában nem, mint valaki, aki azért pár évet lehúzott ebben az iparban, biztos hogy eszem ágában nem lenne ilyen céget csinálni, lényegében bármilyen másik céget csinálok akkor nagyságrenddel kevesebb szívással sokkal de sokkal több pénzt lehetne keresni.

Igen, ideális esetben a magyar állam adna mindent is, valójában meg a mobilos aláírásos megoldás szerintem bőven jó lesz a legtöbb embernek. Nem fognak azzal foglalkozni hogy dokumentumokat archiválgassanak, főleg most, hogy már mindenki átállt ECC-re, annyi ideig meg a legtöbb dokumentumra nincs szükség hogy felül kelljen hitelesíteni, vagy esetleg biztonságosan elarchiválni.

De az egész EU-ban nem nagyon van épkézláb szolgáltató, ez a baj. Lehetne legalább egy cég aki az egész EU-t kiszolgálja, többnyelven, platformfüggetlenül, megfizethető áron. A múltkor ahogy néztem, nem találtam ilyet. Elektronikus archiválásra kértem ajánlatot külföldi cégektől és horror árakat mondtak. Valamiért az egész EU-ban nem nagyon megy ez az eIDAS dolog, ezért kellene akkor a tagállamoknak mögé tenniük ingyenes állami infrastruktúrát, mert eddig a magánszektor nem látott benne fantáziát, pedig a digitalizáció nagyon fontos lenne az egész EU-ban.

Olyan, hogy az állam biztosít valamit, olyan valójában nincs. Olyan van, hogy az állam tud pénzt adni cégeknek, hogy csináljanak valamit, meg tudja az esetleges negatív mérleget megtolni, és ezt reklámozni is tudja mint saját cucc az állampolgárok felé, de maga az állam az egy vezetési forma, önállóan nem képes szolgáltatásokat biztosítani (a legtöbb esetben). A problémát szerintem ebben az esetben az jelenti, hogy nincs olyan - képzett - szakembergárda, aki bevállalná az ezzel a dologgal járó szopásokat. És igen, tudom, hogy jó pénzért mindenkinek korpásodik a haja, de különbség van aközött, hogy korpásodjon, vagy hogy hajhullásod legyen.

Egyébként itt egy réspiac, miért nem alapítasz rá céget te? Nyilván azért, amiért mindenki más: mert vagy nincs meg hozzá a megfelelő szaktudásod, csak fotelből okoskodsz, vagy megvan hozzá a megfelelő szaktudásod, tudod, hogy mekkora szopás ez napi szinten, épp ezért nem csinálod. 

Blog | @hron84

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

via @snq-

Egy jó és megbízható minősített elektronikus archiváló rendszer drága. Mind hardveresen, mind szoftveresen. Csak a hardver (CAS) 100+ millió Ft-nál kezdődik. Pl: Dell EMC Centera - nem tudom, hogy most mi a pontos utódja a Dell EMC-nél, ha van egyáltalán; talán az ECS vagy az ObjectScale.
Persze, össze lehet tákolni / rakni Garázs Bt. módon is - csak az nem egy enterprise megoldás, amire komoly üzletet is lehet építeni.

Ami nagyon érdekes lesz a DÁP aláírásnál, hogy mekkora értékhatárig van biztosítva / szolgáltatói felelősségvállalás mértéke. Ha csak 5-10 millió Ft, akkor azzal még egy új autó vásárlási szerződést is nehéz lesz aláírni. Ráadásul csak magánszemélyként érvényes. Nem hiszem, hogy mondjuk egy cégvezető vagy egyéni vállalkozó használhatná a DÁP-ot aláírásra.
Ez idővel úgyis kiderül.

Amikor elolvasom az ilyen rant-et az első pár mondatból mindig kijön, hogy orbitális információhiány van vagy bias. eIDAS nem kizárólag (és specifikusan nem) csak elektronikus aláírásról szól.
Másrészről elég sok nemzeti szolgáltató van, több köztük ingyenesen biztosít eIDAS kompatibilis XAdES/PAdES aláírást amit borzasztóan könnyű. Sok közül külföldi személyek számára is elérhető. 
Az elektronikus aláírásban azért van timestamp, hogy vizsgálható legyen, hogy az adott időpontban valid volt e az aláírás. Így az aláírás érvényességének elvesztése ne érintse a dokumentum valid voltát. (ide véve az e-seal-t is)

Nem Magyarország specifikus, de az embereknek idegen ez és nem eléggé elterjedt. Az ezt támogató eljárások pont a normál EU direktívák implementálása okán abba a ciklusba érnek mint pl. Magyarországon a DÁP által (jövőben) elvégezhető aláírás.  Sajnos ezt akadályozzák az olyan tényezők, hogy a magyar kormánynak jelenleg a hatalom megőrzés fontosabb ezért a lopás előbbre való, ezért is nincsenek kész ezek a dolgok időben, nem csak az elterjedtség miatt.

itt asszisztáltok Orwellnek , szép világ ez. :)  Lassan kihalnak az öregek kell ez a francnak , élvezzetek.

Persze hogy értem a témát.  Másrészt amikor gyerek koromba olvastam Orwellről már tudtam hogy nem érem meg de csak sikerült az utópiából eljutni a peremére azaz ide és nap mint nap szembesülni vele hogy a környezetembe mennyire másként élnek meg dolgokat emberek.  A HUP közösség is hihetetlenül megosztott, elég csak a komment szekciót olvasgatni, ami nagy részben már nem a szakmai részről szól. Régen nem feszültek ennyire egymásnak a hozzászolok.  https://disztopia2038.hu/ Ezzel a DÁP-pal csak közelebb kerülünk valamihez ami senkinek sem azt jelenti amit gondol róla.

Oké segítek a téma az AVDH megszűnéséről szól a következő helyet itt hagyom neked, hogy az AVDH megszüntetése milyen módon járul hozzá az orwelli  látomásodhoz:

(hint az AVDH-t egy magánszemély által személyes megjelenés alapján létrehozott virtuális fiókon keresztül érted el, AVDH helyett használhattál eddig is bármilyen eIDAS kompatibilis minősített aláírást) 

tudom miről szól, de ez az egész nem oszt nem szoroz, aki akart eddig is és ezek után is megtalálja a pajzson a rést, viszont az információk egyre jobban összeérnek olyanok kezében akiknek ez hatalmi előnyt jelent, ha nem érted az a Te buborékod , de ez nem baj , majd akkor lesz ha valami nem fog tetszeni mert Te másképp gondoltad

Szerkesztve: 2024. 10. 09., sze – 08:08

Ha esetleg megse lesz semmi a dáp-os alairasbol, es nem hosszabbitjak meg az avdh-t, milyen (olcsó) eidasos szolgaltato van, akinel lehet venni minositett alairast (mint maganszemely)?

olcso, hat jo kerdes. Avdh ugye nulla volt, de persze csak itthon volt ervenyes. Node a netlock oldalan latott evi 50 is soknak tunik.

Nem feltetlenul akarok ertekben alairni, hivatalos ugyet inteznj tok jo az avdh, pl nak fele, vagy az nfk (ok siman emailbe kuldott dolgot pattintjak vissza, vagy posta, vagy elektronikus alairas jatszik). De akar egy sima domain atregisztraciorol legyen szo.

Kipróbáltam az ügyfélkapu+-t oathtool-lal. Ment, mint atom.

A családot decemberben átmozgatom ügyfélkapu+-ra.

Úgy tűnik, hogy az újságírók sincsenek toppon.

 

Ruszin Zsolt szerint a könyvelőirodák egyelőre abba az irányba indultak, hogy kihasználják azt a lehetőséget, miszerint egy Ügyfélkapu-fiókhoz (a főnökéhez) a gyakorlatban korlátlan számú mobiltelefont/autentikátort lehet párosítani, így a többiek is használhatják tovább a főnök ügyfélkapuját. Ez azonban valójában kiskapu, amit az üzemeltető Idomsoft bármikor bezárhat a párosítható autentikátorok számának korlátozásával.

 

Van egy közös titok (shared secret), meg egy időpont. A kettő összekombinálásával valahogy létrejön egy 6 számjegyű kód. Teljesen mindegy, hogy korlátozzák-e az authentikátorok számát, vagy nem. A shared secret is jelszó, magyarul két jelszó van: a belépési és a shared secret. Ehhez jön hozzá az aktuális idő. A három input ismeretében bárhonnan képes az ember belépni bármivel. Ha úgy tetszik, ESP32-vel is.

Hiába korlátoz a rendszer egy authentikátorra, mert semmi nem akadályoz, hogy a shared secretet még 67000 telefonnal és 98000 PC-vel megosszam. Magyarul semmi sem változik a szimpla jelszó authentikációhoz képest. Nincs telefonhoz kötve, nincs tablethez kötve, tetszőleges gépen legenerálhatom a 6 jegyű kódot, tetszőleges operációs rendszer tetszőleges programja előállíthatja, tetszőleges mennyiségben.

Egy shared secretet használva simán belépek Linuxról és Androidról is. Kipróbáltam.

 

https://hvg.hu/kkv/20241008_ugyfelkapu-dap-digitalizacio-ugyintezes-kat…

Ezért tartom baromi rossz iránynak az e-személyis login kivezetését, mert az egy és csak egy eszközhöz kapcsolt bejelentkezési lehetőség, aminél gyakorlatilag garantálható, hogy az jelentkezik be, akinek a birtokában van az azonosítóeszköz és ismeri a hozzá tartozó megfelelő méretű PIN-t, mivel az eszköz nem másolható. A standard ToTP alapvetően egy másolható eszközre bízza a második faktort, bár ezt is meg lehet csűrni-csavarni azzal, hogy a device azonosítását is beleszövik az így már nem szabványos második faktorba. De ez egyedi klienst, illetve egyedileg fejlesztett szerver oldali komponenst igényel.
Szóval egyelőre megy, de az eID-s login, mivel a 2. faktort biztosító szoftver és a szerver oldal is ugyanannál a fejlesztőnél van, így a megrendelő döntése alapján simán be lehet hozni egy egyedi megoldást, ami device azonosítását is megoldja, és n darab eszközre korlátozza az adott állampolgár megszemélyesítését az ügyfélkapu felé.

Elosztott jelszót jelent röviden. A jelszó egyik felét a PC-n tárolod a böngészőben, a másik felét meg az authentikátor alkalmazás tárolja.

 

A hozzáadott érték minimális:

- hosszabb lesz a jelszavad

- két helyen lesz tárolva

 

Ugyanakkor kriptográfiailag a történet egyenértékű a szimpla jelszavas azonosítással.

És biztonságos módon tárolni - na ez az, amiben gondok vannak/lehetnek - hiszen nincs semmilyen garancia arra nézve, hogy ezek a secret-ek nem vihetők el, nem másolhatók le n+1 példányban akár észrevétlenül. A személyi, mint fizikai eszköz (benne a kívülről nem elérhető privát kulcs) többszörözése azért khm. kifejezetten nehéz feladat. Volt addig, amíg az eID app meg nem jelent, lehetővé téve bárkinek bárki személyijét behúzni az alkalmazásba a PIN-kód ismeretében - onnantól az eredeti hardveres azonosítóeszköz pin-kódja (tudás), illetve birtoklása (kártyaolvasóba berakott személyi) nem szükséges ahhoz, hogy adott illetőként azonosítsa magát az ügyfélkapu felé - vagy akár egy rendőri igazoltatásnál.

Tudom, corner-case, hogy valakinek az e-személyije ideiglenesen olyan kézbe kerül, aki valahogy megismerte a megfelelő PIN-t, és annál a támadónál van arra alkalmas mobiltelefon, és...

Nem állítottam, hogy a TOTP jobb, mintha valami tokenen volna, azt vitattam, hogy minimális előnye van A TOTPnek egy sima jelszóhoz képest. Mert persze lehet szarul csinálni, de nem túl nehezen lehet úgy is jól, hogy én reasonably biztonságosan tárolom a shared secretet, és nem kell mindenféle megbízhatatlan hálózaton kiadnom a kezemből állandóan.

Fogsz egy minimálisan szükséges képességű telefont, egy randomjoska gugli fiókot, aztán hajrá... Ha ennyire nagyon parázol attól, hogy úristenmittudnakmegrólad... Igen, a "hol vagy" az a ufk+ esetén is nagyon jól behatárolható IP-cím alapján... De te tudod, hogyan akarod magadat szivatni... (Ugyebár a NAV által elkészült szja bevallás tervezetet sem fogod tudni elérni máshogy, úgyhogy nulláról kell majd neked összevadászni minden adatot (helyesen és pontosan!), de te tudod... (Egyébként az eID képes PIN-kóddal is menni, bár a 6 számjegy kontra biometria kapcsán nekem egyelőre ez utóbbi tűnik jobbnak... )

Jelenleg, de dolgoznak már a biometria nélküli DÁP-on. Olvasd el a google play válaszokat a hozzászólásoknál. Az IdomSoft visszaválaszol.

Szóval lesz DÁP biometria nélkül, gyanítom, hogy 2027-ig meg is engedik, hogy így lépj be.

Az erős azonosításnál kell a "birtoklás" is, ha tényleg jól akarjuk csinálni. Az e-személyinél a birtoklás egy és csak egy eszközhöz köti az azonosítást, a ToTP meg az n darabból egyiknek a birtoklásához. Azaz a megfelelő tudás birtokában n user azonosíthatja magát adott személyként - és ezt az érintett akár észlelni sem tudja, mivel a totp secret tárolható olyan szoftveres megoldásban, ahonnan azt észrevétlenül el lehet vinni.

 

És mi van, ha nincs okostelefonod?

Pont ugyanaz van, mint a 2000-es évek elején, a kormány Microsoft Windows alá írt exe fájlokat osztott meg, mer az úgyis jó.

Akkor legalább volt wine, hogy a kormányzati szarságokat hellyel-közzel futtatni tudjuk.

Most előírják, hogy kötelező vagy Android, vagy iPhone okostelefont vásárolnod. Miért is?

 

Ez jó lesz nekünk? A történelem megismétli önmagát, csak sokkal rosszabb leosztásokkal.

Ha nincs okostelefonod, akkor kiveszel szabadságot, besétálsz a megfelelő hivatalba/hatósághoz, beszélgetsz az ottani emberekkel... (Nem te írtad, hogy szereted ezeket a dolgokat?)

Az ügyfélkapu-val elérhető szolgáltatásokat ilyen módon is igénybe lehet venni - az üfk és a rá épülő szolgáltatások a használatot teszik kényelmesebbé, ennyi, és nem több.

 

Mi a kapcsolat az e-kréta (mobilos és webes felülete is van) és az eID / ügyfélkapu plusz authentikációs módjainak változása között? Mert én nem látok ilyet... Vagy arra akarsz célozni, hogy "nekünsevótokostelefonunkosztmégis..."? Ebbe a mocsárba nem húzol le - neked a lovaskocsi meg a penna-ténta-papíros a módi - másnak meg más...

Az e-személyis azonosításnak? Mondjuk az, hogy technológiából adódóan egy és csak egy példányban létező eszközzel történik az azonosítás, azaz nem elég egyszer rövid időre hozzáférni az okmányhoz és a kapcsolódó PIN-kódhoz, amivel tetszőleges számú mobiltelefonra fel lehet pattintani az adott személy azonosítására alkalmas szoftvert...

Ha ez tömegesen előforduló jelenség lesz, akkor az állam nyilván le tudja korlátozni 1 eszközre a DÁP-ot központilag, bármikor. Egyébként pedig elvárt az állampolgártól a gondosság, hogy ne írja filctollal a pint a személyire, miegymás. Én nem látok ebben kivetnivalót. Nem kötelező PIN kódot kérni a személyihez, ha kérsz, akkor nagyobb a felelősséged is, ennyi. A bankok sem térítenek ha az ügyfél volt hülye.

> Ha ez tömegesen előforduló jelenség lesz, akkor az állam nyilván le tudja korlátozni 1 eszközre a DÁP-ot központilag, bármikor. 

A nulladik időpillanattól ez kellene legyen, mert ez biztosítaná az identitáslopás megakadályozását, ami jelenleg is óriási probléma nemzetközileg is. Jelenleg az állam nyitott kapukat hagy ennek.

> Egyébként pedig elvárt az állampolgártól a gondosság, hogy ne írja filctollal a pint a személyire, miegymás

Hát, az állam ebben az esetben nem ismeri az állampolgárait. És nem is csak az a baj, hogy fölírják a PIN-t, hanem hogy a PIN 1234, 1111 vagy 0000 lesz. Mert rengeteg a szögegyszerű ember, akinek maga a PIN nyűg és teher, és egyszeűen nem érti azt, hogy ez őt védi, mert "ő nem akar ilyesmiket megjegyezni, hagyják őt békén". És egy kvázi államilag kötelező valaminél ezekre az emberekre is lőni kell sajnos, nincs olyan, hogy "elvárható gondosság".

> A bankok sem térítenek ha az ügyfél volt hülye.

Igazad van, és ez jó is így. Ám, egy identitáslopás esetén sokkal nehezebb megállapítani, ha az ügyfél volt a hülye, és konkrét károkat lehet okozni nagyon sok embernek, nem csak annak, aki hülye volt. És itt már felmerül az állam felelőssége is, hogy vajon jól tervezte-e meg ezt a rendszert.

Blog | @hron84

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

via @snq-

Attól, hogy 1 eszközön futhat DÁP még ellopható az identitás. Továbbra sem lesz kötelező PIN-t aktiválni az eSzemélyi-n. Van elvárható gondosság, olyanannyira, hogy a jogban is ismert fogalom. A bankok sem szaroznak sokat azzal, hogy megállapítsák ki volt a hülye: alap, hogy az ügyfél. Egyébként pedig mindig a hülyének kell megtéríteni a másik kárát, ha a hülyeségével okozott kárt.

Az állam nem felelős azért, ha az állampolgár hülye. Megadja a lehetőséget mindeninek, hogy hülyén, de biztonságban éljen, pl azzal, hogy nem aktiválja a PIN-t az eSzemélyin, nem használ DÁP-ot, satöbbi. Ennél többet nem kell tennie.

Az okmányt is le lehet nyúlni, és amíg az érintett nem veszi észre, hogy nincs a birtokában, addig hoizzá hasonló fizimiskájú támadó tudja magát azzal igazolni, a megtámadott illető identitását "felvéve".
Azzal, hogy az egy és csak egy valid eszköz van (e-személyi) ami jogilag egyértelműen adott személyt azonosít helyett tetszőleges számban létrehozható mobiltelefonos identitás ugyanehhez a személyhez az identitáslopásra jóval nagyobb lehetőség van. Ez olyan,mintha mondjuk eddig Yubikey tokennel használtál volna egy szolgáltatást, de az új rendszerben egy másolható eszközre térnének át. 

Semmiféle igazolvány nem tudja garantálni önmagában, hogy azt a jogosultja használja. Ezért van az, egyéb faktoroknak is meg kell majd majd felelned ha tényleg necces dologról van szó – összenézik a fényképed a fejeddel, ellenőrzik az eSzemélyin rögzített ujjlenyomatod a valóssal, stb. Ha egy lenyúlt DÁP identitással rohadt nagy kárt lehet okozni akár magadnak akár másnak, akkor ott valójában az a gond, hogy hiányoznak az egyéb authentikációs faktorok. Ott nem lenne szabad a DÁP-ot engedni autentikációra önmagában és ennyi.

Jelenleg a DÁP kb az ügyfélkapu belépésre jó ahol egyébként még a 2FA sem kötelező, a könyvelők pedig .doc fájlokba gyűjtik az ügyfeleik ügyfélkapu loginját. Ez jelenleg egy elméleti sebezhetőség és messze nem a leggyengébb láncszem amennyiben valaki az ügyfélkapuhoz akar hozzáférni más nevében. Hogy a jövőben mire lesz jó, az majd kiderül, de biztos vagyok benne, hogy pl még bankszámlanyitáshoz sem lesz elég a DÁP magában, hanem marad a videóhívás ahol megnézik a fejed is mellé.

Igen, a könyvelők viszont nem szeretik a felelőséget. Ezért amikor ezt a kötelező ügyfélkapuzást bevezették ahelyett, hogy meghatalmazást kértek volna sorra zavarták be a vállakozókat ügyfélkapuért természetesen a könyvelőiroda email címével.

Hiába volt kifüggesztve a NAV-os állásfoglalás, hogy ezt meghatalmazással kellene. :P

Úgyhogy ez nem kényszerképzet hanem a való világ , ezért sírnak amúgy az Ügyfélkapu+ miatt. (nem tudom őket sajnálni)

Mindent lehet rosszul használni. Ennyi. A HU-faktortól nem lehet a HU-t megvédeni, maximum edukálni lehet... (HU: Hülye User)
 

Aki sír az üfk+ miatt, az sírjon, senki sem hatódik meg rajta - a megbízója meg (talán) rájön, hogy a saját identitását nem kéne odaadni a könyvelőnek úgy midnenestől - ahogy azt korábban tette, amíg usernév/jelszó páros elég volt a bejelentkezéshez.

Igen, sokan fognak a sima üfk kihajítása miatt copni - nem tudom sajnálni őket...

Akkor poénból találta ki a NAV az UJEGYKE (leánykori nevén EGYKE nyomtatványt). Nem pedig az adózói képviselet bejelentésére. 

Arról nem beszélve, ha a cégvezér kiadja a könyvelőgizinek az ügyfélkapu felhasználónevét / jelszavát akkor könyvelőgizi nem csak a NAV-nál intézkedhet cégvezetőként hanem bárhol (ugye jó esélyel cégkapu hozzáférés is van mellete :))

Az EGYKE-nek egy szerepe van, hogy nyilatkozhatsz ki kezelheti a cég számára érkező iratokat és adót vallhat be. A könyvelő csak az általa adott jognyilatkozatokért felel, ha az abban lévő megfelel annak a tartalomnak, amit a könyvelő a cégtől kapott akkor semmi más felelőssége nincs. Ez a szakmai felelősség. Ez a felelősség akkor is fennáll, ha ők csak könyvelnek de a bevallást a vállalkozó adja be, vagy a vállalkozó nevében a könyvelő tölti fel. Csak könnyebb a problémát a könyvelőre tolni ha nem ment be a bevallás időben, vagy hibás. De ha ezen vitatkoztok a könyvelőddel, akkor jobb ha otthagyod. 

Ez esetben vitatható a felelősség, mert de facto a benyújtó felel az adatokért, márpedig ha Cégesch K. József identitásával történik a bevallás benyújtása Cégesch K. József vállalkozásáról, akkor C. K. József lehet felháborodva, de első körben ő felel, mivel a NAV felé ő nyújtotta be a bevallást. Ha  C. K. J. vállalkozása nevében a P. Manczi könyvelőirodából Pczi Manci nyújtotta be, C. K. J. cégvezető meghatalmazásának a birtokában, akkor P. Manci az, aki elsődlegesen felel az adatok valódiságáért és a rendelkezésére álló adatok alapján a helyességéért.
 

Ez esetben vitatható a felelősség, mert de facto a benyújtó felel az adatokért

Ezt azért meg kellene vizsgálnod, mert a cég vezetője felel a könyvelésbe átadott anyagokért, a könyvelő csak a bevallás helyességért felel. Azért pedig akkor is ha nem külön hozzáféréssel adja be. 

Hát, én nem nagyon (nagyon nem) értek ezekhez, de itt tippre azért feszül némi ellentmondás az elmélet és a gyakorlat között :) Szerintem is ez kicsit ilyen hiedelem alapú, és nem fogja megúszni a kedves könyvelő, ha tényleg oda kerül a sor, de azért jóval nehezebb dolga lesz a kliensnek. Mer' még ha az ki is derül hamar, hogy ja, hát ő könyvelt, a gázosabb szarokra még mindig tárogatja majd a kezét a könyvelő, hogy ja, hát azt nem ő, sőt direkt mondtam is, hogy erre figyeljen, hogy el ne rontsa... És mivel az ilyesmi gyakran kéz a kézben jár valami kreatív könyveléssel, meg svarccal, egyébként se nagyon fognak bíróságon pattogni egymással, kitalálnak vmit, ember befizeti a büntit, aztán vagy elmegy máshoz, vagy nem, de a könyvelő, az kb radar alatt marad.

A másik, amire gondolni tudok, hogy szerintem könyveléshez is kell biztosítás, mint az ügyvédeknek, és egyrészt azon spórolnak, másrészt meg ha szar van, nem kell annak a kontójára kártalanítani az ügyfelet, ezzel egyrészt további költségbe, másrészt meg további kellemetlen kérdezősködésbe keveredni.

Aztán persze, ha mégis bukik a buli, akkor igazából mindenki nagyobbat fog szívni jó eséllyel...

Nem érted, vagy nem akarod érteni? Nagyon nem mindegy, hogy egy kizárólag egy példányban létező, nem másolható eszköz az, amit azonosításra lehet használni, vagy egy (ebből "származtatott") olyan eszköz, amiből több is létezhet.

A sima üfkapu-t már régen be kellett volna szánatni a sima usernév/jelszó azonosítás miatt, mivel az elég régóta nem számít erős azonosításnak. Csak ugye voltak olyan szakrendszerek, amik nem voltak képesek megugrani az ügyfélkapu+ kompatibilis működést.

 

Értem, de minden biztonsági rendszernek csak annyira kell jónak lennie mint amekkora a fenyegetés és ez az elv itt nem sérül. Nem tömegesen kihasználható az a támadási vektor amitől parázol, mivel ahol nem babra megy a játék, ott a DÁP app csak egy faktor lesz az authentikációban. Nem érdemes erre teljesen rácsavarodni.

Egy NEM sokszorozható eszközt kivezetnek, ez a gond, és helyette CSAK olyan lesz, amiből lehet több példány.

"a DÁP app csak egy faktor lesz az authentikációban"

Egy olyan eszköz, amiből akármennyi is azonosíthatja ugyanazt a személyt, anélkül, hogy tudna róla az érintett. És kérdés, hogy a DÁP-os QR-kódos auth során az eszközt egyedileg azonosító adat (jó esetben még a geolokációs adat is) vajon eljut-e a ügyfélkapuhoz, és ott naplózzák-e? (Bár ez csak utólagos vita esetén lehet egy információ arról, hogy a vitatott bejelentkezés honnan, hogyan történt.)

 

Azért a személyit és a PIN-t egyidejűleg nem egyszerű megszerezni. Gyanítom, hogy az átlagembernek 80%-ban arról sincs fogalma, hogy van hozzá PIN, nemhogy a tartalma :) Ráadásul előfordul, hogy az okmányirodában nem is foglalkoznak a kezdeti PIN beállítással, vagyis marad az, amit a borítékban kiküldtek, és mivel viszonylag kevés embernek van e-személyi olvasója, amivel ez esetleg megváltoztatható, az úgy is marad.

A chip-nek ami a Szig-ben van, nincs olyan művelete, hogy "nosza add ki a privát kulcsot", csak olyan, hogy "készíts aláírást (signature)" a privát kulcs használatával (non-repudiation).

Kiegészítő érdekességek:
* titkosítani (encryption) nem lehet vele, egyrészt mert a cert nem engedi, másrész mert EC-s kulcs
* október 1-óta nem kérhetsz ilyen funkciót a Szig-be (korábban sem nagyon reklámozták)