Fórumok
Én szerettem volna ma bekapcsolni a 2FA-t az Ügyfélkapuhoz. Úgy gondoltam, hogy 2024. januárjára már elég stabil ahhoz, hogy használni is lehessen. Picit tévedtem.
A https://ugyfelkapu.gov.hu/felhasznalo/adminisztracio/totp/eszkozparosit… oldalon ugyanis a jelszóbeviteli mező legfeljebb 30 karaktert enged bevinni. Komolyan, 2024-ben ott tartunk, hogy korlátozzák a jelszó hosszát? Nooormáááális, Margit.... Utoljára IBM termékben találkoztam súlyos jelszólimitációval (15 karakter).
Abban bíztam, hogy 2024-re ezt a téveszmét kinövik a fejlesztők. Tévedtem.
Persze rögtön írtam is a https://ugyfelkapu.gov.hu/kapcsolat űrlapon keresztül. Kíváncsi leszek, hogy mikorra javítják ki ezt a hibát.
Hozzászólások
hat azert 30 karakter nem akkora korlat szerintem... minek ennel hosszabb pw? gondolom megneztek hogy a hash entropiaja mennyi, annal hosszabb jelszonak ugysincs ertelme.
De. Nekem 30 karakter nem elég. Főképp ismerve az IT rendszerek védelmét, jelszószivárgásra hajlamosságát. Bizalmatlan vagyok.
Normál weboldalaknál megelégszem a 24 karakterrel. Fontosabb rendszereknél 32 karakter, nagyon kritikus rendszernél (nálam az Ügyfélkapu is ide tartozik) 48 karakteres jelszavakat használok. Tudom, év vagyok a hülye.
de miert?
ha ellopjak, tokmind1 hogy 8 vagy 80 hosszu, akkor is el lesz lopva.
ha meg hasht kell torni, akkor a technika mai allasa alapjan 12 karakter hossz folott mar nem eri meg bruteforcolni, mert evekig tart, es a rainbow tabla se jatszik mar ilyen hossznal mert sok petabyte meretu lenne.
Egyrészt a hit. Minél hosszabb, annál nehezebben törik fel. Akkor is, ha ellopják. Nyilván ha a kedves rendszer titkosítatlanul tárolja a jelszavakat, akkor mindegy a hossz.
Továbbá van ez a jelszócsere mánia, ami már nem divat, sőt, ellenjavallt - lásd: NIST ajánlás. Egy megfelelően hosszú jelszó / jelmondat esetén emiatt se kell aggódnom.
Ha célzott a támadás - pl: magyarorszag.hu ellen -, akkor megérheti bevetni az erőforrásokat.
De miert ne? Ugyis a hash-t kell csak tarolni szerver oldalon, az meg ugyanakkora, jelszo meretetol fuggetlenul.
Avagy, az egvilagon semmilyen extra lepest, befektetest vagy egyebet nem igenyel a nagyobb jelszo engedelyezese. Hovatovabb, az az extra nehezseg, hogy limitet kell adni a jelszo hosszanak es lekezelni/megjeleniteni az ebbol fakado hibat.
Tehat a kerdes inkabb az, miert szurunk ki sajat magunkkal? Ertelmetlen policy #sok.
És így jött létre egy jó kis 'buffer overflow' ;)
zrubi.hu
Miért ne lehetne 2 GB-nál nagyobb jelszavam. Miért akarnak KORLÁTOZNI????!!!!!
Én ezt teljesen valid igényként kezelem, de AI-val fogom ellenőrizni, hogy ezt neked kézzel kötelező begépelni, semmi kopipaszta vagy autofillér.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Miért van egy olyan érzésem, hogy nem hash-elve tárolják a jelszavakat...?
Na miért...?
az, hogy most a 30 karakter jónak tűnik, nem biztos, hogy most megszerzett információ nem lesz aktuális post-quantum korszakban. lásd: harvest now, decrypr later
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Amikor a 30 karakter kevés lesz, nem hiszem, hogy a jelszó hossza fogja meghatározni a biztonságát, sőt valószinű nem is jelszavakat fogunk használni.
mire lesz elerheto technika a 30+ jelszo toresehez, a jelszo ervenyessege mar ugyis lejar :)
Valaki számoljon velem.
62 alfanumerikus karakter + 33 non-alfanumerikus karakter = 95
2^X = 95^(30)*2^S ahol X a hash mérete, és S a salt mérete
=> X-S = 30 * log2(95) ~ 60
=> ~60 bittel nagyobb a hash méret a salt mérethez képest ?
(1) A 30*log2(95) nem ~60, hanem ~197. Tehát a jelszóban 197 bitnyi infó van.
(2) Miért számít, hogy a salt és a jelszó egymáshoz képest mekkorák?
A jelszó legyen jó erős, hogy ne lehessen nyers erővel törni. A salt is legyen jó erős, hogy ne lehessen érdemben szivárványtáblát gyártani előre. A végső hash-nak pedig szerintem nem kell annyi bittel rendelkeznie, mint a salt+pass összesen; elég, ha jól kever a hash. Például 128 bites salt-ot ragasztunk a fenti 197 bites jelszó elé, az 325 bit információ, de (szerintem) bőven jó, ha a SHA256 kimenetet tárolunk a salt mellett.
Esetleg az merülhet fel (csak találgatok, hogy mire vonatkozott a kérdőjeled), hogy "helyet pazarlunk"; nyilván SHA256-ba nem érdemes 256 bitnél kevesebb információt (salt+pass) belerakni. De a jelszó eleve 197 bites, úgyhogy ebből a szempontból már egy 64 bites salt is elég volna (197+64=261>=256).
SZERK. Neked úgy jött ki a 60, hogy nem 30*log2(95)-öt számoltál, hanem 30*log10(95)-öt!
Én sem érzem ezt erős korlátnak, ahol nem limitálják kevesebbre, 24 karakteres jelszavakat használok, de többre sosem volt igényem, ettől éppen nem lesz rosszabb a szolgáltatás (tök jól működik 2FA-val is).
Sőt:
Ezt hogy kell erteni? En bekapcsolom a 2FA-t, de ha valaki ellopja a jelszavam, valaszthat 2FA nelkuli belepest? Nice.
Ezt úgy kell érteni, ha bekapcsolod a 2FA-t akkor mondjuk a NAV-os mobilappba soha a büdös életben nem fogsz tudni belépni, mert a sima ügyfélkapuval próbál azonosítani és a 2FA-t miatt simán hibát dob belépéskor.
Vagy ott van a https://gate.gov.hu -n (régi MOHU auth gondolom még van egy két szolgáltatás ami ezt használja) amin máig simán jelszóval be tudsz lépni akkor is ha be van kapcsolva a 2FA mert miért ne.
Jól ki van ez találva.
Ez mondjuk nem igaz.
Az elején még sajnos igaz volt - például a Lechner (nem)tudásközpont nevű társulat (közműtérkép pl.) sem tudta a pluszos logint ...
Ez a bejegyzés januárban keletkezett. Ez már tavaly is szépen ment. Szóval akkor sem volt igaz a kijelentés amikor ide kerül, most még inkább nem igaz.
Ha be van kapcsolva a 2FA-d, de oda kattintasz ezen a felületen, hogy Ügyfélkapu, akkor nem enged be: kapsz egy generic hibaüzenetet, hogy elírtad a jelszavadat, vagy van-e 2FA-d Ha be van kapcsolva a 2FA-d, akkor a fenti felületen az Ügyfélkapu+-t kell választanod. Securityben nem sérül, de aki ezt a UI-t kitalálta...
(de vannak/voltak olyan állami oldalak, amik a beállított 2FA ellenére beengedtek, ami nem az új, képen látható ügyfélkaput használta, hanem még ennek valami régi verzióján keresztül léptetett be... lassan ezek kikopnak talán)
Tényleg több mint harminc karaktert szeretnél ügyfélkapus jelszónak? :) A KAÜ süti cuminál bosszantó lehet ha hosszú.
Neked be van állítva valami script, ami kaparássza a HUP-ot és ha ügyfélkapu téma bukkan fel, akkor riaszt, vagy állandóan itt vagy egy másik nickkel és ilyenkor átjelentkezel erre? :D
Én az utóbbira tippelek.
trey @ gépház
Eddig is itt voltam, ez az egy nickem van. :)
Amúgy érdekes, hogy a jelszóváltoztatásnál 150 karakter a password length limit, a 2FA hozzáadásánál meg csak 30 karakter, valaki megint minőségi munkát végzett. Én a helyében megpróbálnám a 2FA-nál fentebbrakni a password input maxlength-jét 150-re, mert valószínűleg az a helyes érték. Bár ha 150 karakterbe se fér bele akkor ez sem megoldás és lehet kibertámadásnak értékelik. :)
lehet 120 karakter kell nekik a 2FA infok tarolasara igy mar csak 30 marad az sql rekordban a jelszonak :)
Engem pont ez triggerelt. Hogy lehet olyan béna rendszert alkotni, ahol egyik felületen X hosszú, másik felületen belépve csak X/5 hosszú jelszót tudok beírni? Ez így nem következetes, megtévesztő.
A vicc, hogy még értelmes hibaüzenetet se adott az oldal. Nekem kellett sakkozgatni, hogy miért nem jó a jelszavam - amivel 1 perccel korábban léptem be.
Decemberben valaki redditen ugyanilyen balfékségre panaszkodott a webkincstár Androidos appja kapcsán, lehet ugyanaz kódolta?
Nekem lejárt a jelszavam decemberben, jött róla mail('Ügyfélkapujának bejelentkezési jelszava 2023.12.17 napon lejár'). Mégis be tudok lépni??? Nem is jelezte, hogy változtassam meg simán beengedett. Kíváncsian várom mikor veszti el érvényességét.
update:
A tarhely.gov.hu -ra simán be tudtam lépni, de a https://ugyfelkapu.gov.hu/ -ra belépve egyből kérte a jelszó megváltoztatását. Természetesen utána tárhely-hez is az új jelszó kellett.
Azt vártam volna, hogy dec 17 után oda sem tudok belépni a régi jelszóval.
Az emailben ott van, hogy lejár ugyan az adott dátumon, de utána még 60 napig be tudsz lépni a régivel és kötelező az azonnali váltás (ahogy írtad). Ha kifutsz ebből a 60 napból, akkor már csak személyesen tudod megváltoztatni.
OK, de akkor is furcsa, hogy a tarhely.gov.hu -ra simán beengedett ügyfélkapus azonosítást használva. Még ma is néztem és semmi sem utalt arra, h bármi probléma lenne, nem kérte a jelszó megváltoztatását. Ha nincs ez a topic akkor meg sem keresem az emailt és nem keresem fel az ugyfelkapu.gov.hu -t ahol belépés után egyből kérte a jelszó megváltoztatását.
Ezek szerint 60 napig használhattam volna a tarhely.gov.hu -t majd rohantam volna az okmányirodába mert már nem engedi a jelszó megváltoztatását ? Ez elég furcsa. Treynek biztos nem így működik. :)
Jaaaa, hogy a tarhely.gov.hu nem kérte a jelszómódosítást. Gondolom nem készültek fel arra, hogy valaki az ugyfelkapu.gov.hu helyett azzal indít. :-)
Ez azért is érdekes felvetés, mert rendszeresen jön szembe olyan hivatalos e-mail, amiben direkt a tárhely van belinkelve. (Persze, értem.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Általában a kapcsolt rendszerek nem mindig dobnak a jelszóváltós felületre egy SSO megoldás esetén. Mi is szívunk azzal, hogy némelyik megoldás nem dobja a parasztot automatikusan a jelszóváltós felületre, amikor lejár neki, hanem vagy beengedi, vagy nem engedi be egyáltalán, de a jelszóváltás az így fel sem merül ötlet szinten se, hiába tudná a termék.
Blog | @hron84
via @snq-
A párom jelszava idén áprilsban lejárt. A mai napig be tud lépni az ugyfelkapu.gov.hu oldalon anélkül, hogy kötelező jelszóváltoztatást kérne.
Frissítés - 2024.11.06.:
Felemelték a limitet 150 karakterre. Picit lassan ment a változtatási igényem lefocizása. A lényeg: működik. Így már boldog Ügyfélkapu+ felhasználó vagyok. Mindig van remény...
Mit lehet erre írni? Maximum annyit, hogy gratulálok neked. Szimpla állampolgár létedre sikerült elérned, hogy egy közhivatal (gondolom annak számít) a panaszodat kezelte, ráadásul úgy ahogy te szeretted volna. Nekem még ilyen élményem nem volt. Irigyellek.
Még nincs aláírásom.
És relatív gyorsan, 10 hónap alatt végigfutott a teljes folyamat...
Azért a képhez hozzátartozik:
- Több ticketet nyitottam.
- Ha leráztak, akkor vártam pár hetet, esetleg hónapot és újra próbálkoztam a hibámmal.
Konteó on: Még az is lehet, hogy látják, hogy a DÁP nem fog tudni mindent határidőre. Már most is csúszásban vannak. Ergo az Ügyfélkapu+-ra átállás elengedhetetlenné vált szinte mindenkinél.
Teljesen jól csináltad, minden gúny v. cinizmus nélkül írom.
Köszönöm.
Szerintem nagyon fontos a pozitív híreket, információkat is megosztani. Sokkal vidámabbá teszi a hallgatók életét is. Feltölt picit mindenkit.
picit offtopic: sikerült valakinek belőnie a keepassxc-t az ügyfélkapu+ login formhoz? Mivel a usr/pwd/totp field nem ugyanazon a formon belül van, nem tudom rávenni, hogy mindent helyesen töltsön ki (manuálisan ok, de az ugye nem kunszt :) )
"The only valid measurement of code quality: WTFs/min"
> sikerült valakinek belőnie a keepassxc-t az ügyfélkapu+
persze
> manuálisan ok, de az ugye nem kunszt :)
ja hogy ugy. hat nekem minden manualisan megy, nem szeretem a bongeszobe (is) integralt jelszokezelot...
keepassxc tudja...
A kérdés lényege az volt, hogy milyen beállításokkal tudja?
A default módszer nekem nem megy. Egyszerre nem tudom kiválasztani a usr/pwd/totp fieldet, mert nincs olyan form állapot amikor mindhárom látszódna. Ha megpróbálom 2 részletben, akkor meg a keveri a pwd/totp fieldet (valszeg azonos id-juk van, de ezt a js-ből nem vakartam ki).
Ha rábökök egy fieldre, jobbklikkel meg tudom mondani, hogy mit rakjon bele a három lehetőségből…de nem ez a cél.
Értem a szeku megfontolásokat, de van az a scenario amikor ez a kisebbik rossz. (pl idős rokon, akinek a totp-t megérteni/alkalmazni kb lehetetlen, de intézkedni viszont akar).
"The only valid measurement of code quality: WTFs/min"
https://addons.mozilla.org/en-US/firefox/addon/totp/
Ez nem segit? 2 katt es a clipboardon van a totp. Beilleszteni kell tudni...
Ha ez keves, akkor Igaz a nav-os szamlazo belepeshez, de én írtam egy greasemonkey scriptet, ami begenerálja a totp-t a formba. Ha kell akkor a vazat meg tudom osztani, a formid-t kell atirni...
Hmm?
OK, pontosítok. A KeePassXC pluginben (Firefox) van olyan, hogy: Fill TOTP
Nyitó oldal, user/pw listából kiválasztva (mivel nálam több is van).
Következő oldalon ahol a 2FA-t kéri: jobb gomb, KeepAssXC -> Fill TOTP
Azért ez megugorható, 70 feletti apukámnak is szerintem ez lesz. (Linuxon még nem próbáltam)
Ez a manuális beillesztés, ez ok. De nekem az automatikus field detect feature-t kellene összehoznom :/
Sokszor hiszem én is, hogy könnyen megugorható valami, aztán szembejön a valóság. :(
"The only valid measurement of code quality: WTFs/min"
Erre nekem is van 1 szállóigém. Szoktam emlegetni mikor valaki be akar húzni a csőbe mikor rámlőcsölne valamilyen egyszerűnek tünő nemszeretem melót. Amiről ált. mindig kiderül h. sokkal hosszabb és szarabb meló lett, mint ahogyan előadták.
Sztori röviden: helyi szaki - kvázi menedzser kolléga - kiadta nekem a primitiv projectet: ... ne izgulj gyorsan megleszel vele, hisz "csakegy izé ". Aztán a "csakegy izé"-t több mint 10 hónapig vittem, mert közben kiderült mindenféle product bug, amiket a vendor is csak 6-8 hónappal később javítgatott (többedszerre sikerült nekik is). Pedig reális munka talán 1-2 hét lett volna vele (tesztelés included, meg dummy guide írása az üzemeltetős bandának).
Jahogy ja. Már értem.
https://totp.app/
Mivel böngészőben fut és neked is böngészőben kell az eredmény ezért gondolom elég egyszerűen leprogramozható.
Nem, én a keepassxc-be integrált totp-ről beszélek.
Azon belül is a browser extension féle “autofill”-ről… (nem az auto-typeról!)
"The only valid measurement of code quality: WTFs/min"
Rész-siker:
{USERNAME}{TAB}{PASSWORD}{ENTER}{DELAY 2000}{TOTP}{ENTER}
A user/pw után elveszti a fókuszt az oldal, de ha belekattintok a TOTP mezőbe 2 másodpercen belül akkor kitölti és belép.
Elképesztő egyébként, hogy mennyire nem ér semmit ez a 2FA a széles tömegek gyakorlatában majd.
Az elmélet ugye úgy hangzik, hogy az első faktor (hagyományosan a jelszó) az, amit "tudsz". Ehhez jönne hozzá a második faktor, amit nem tudsz, viszont "birtokolsz".
A tipikus gyakorlat viszont az, hogy már az első faktor (a szolgáltatás-specifikus jelszó) is olyan, amit "birtokolsz" (és lényegében semmit nem kell hozzá tudni, max. a telefont kinyitni arccal, ujjlenyomattal, *izommemóriából* PIN-nel vagy gesztussal, ...). A második faktor -- a TOTP alapját képező titkos URL -- is csak olyan lesz, amit "birtokolsz"; ráadásul pont ugyanazon a fizikai tárgyon, és pont ugyanazzal a művelettel lehet feloldani, mint az első faktort. A korábbi első faktor sosem volt a képernyőn, az emberek nem gépelték be; tehát az, hogy a statikus jelszót eltanulják (lelessék), az nem volt valós veszély eddig sem. Így a két faktort pontosan ugyanakkora (közös) erőfeszítéssel lehet megszerezni: el kell lopni az okostelefont, és a telefon feloldását kell megoldani.
Az egész 2FA őrületnek annyi a gyakorlati következménye a tömegek számára, hogy sokkal nehezebb lesz használni egy csomó szolgáltatást, viszont semmivel sem lesz biztonságosabb, mint a 1FA.
(Én is azért rágódom ezen egyébként, mert bár magamnak megoldottam asztali gépre zbarimg és (gpg-re alapuló) "pass otp" kombinációval, arról fogalmam sincs, hogy mit javasoljak a családtagjaimnak. Mivel számukra a 2FA-ból származó elméleti biztonságnövekedés a gyakorlatban használhatatlan, ahogy a legtöbb ember számára is, valószínűleg arra kell törekednem, hogy legalább a lehető legkevésbé legyen kényelmetlen.)
Azt felejted el, hogy a legtöbb "jelszó-lopás", az újrahasznált jelszavakból van, feltörik a kispista bt php webshop-ját, viszik a cleartext jelszót a mysql adatbázisból, mellé az email cimet, felkerül a darkwebes, tizmillió lopott jelszót tartalmazó adatbázisba, majd ugyanazzal jelszóval be lehet lépni az email fiókjába és 20 másik szolgáltatásába.
Na ezt helyből megakadályozza még a leggagyibb, ugyanott tárolt TOTP 2FA is, ugyanis a secret hozzá egyedi lesz minden egyes szolgáltatásban és onnantól hiába van meg a user jelszava, nem tudnak más, 2FA-t használó szolgálatásba belépni a user nevében.
Jogos -- az "újrahasznált jelszó" mint támadási felület eszembe sem jutott; szerintem az utóbbi egy (kettő?) évtizedben csak generált jelszavaim voltak (és amikor rajtam múlott, másnak is csak generálni voltam hajlandó).
Az okoseszközök korában mi szól amellett, hogy az emberek kézzel válasszanak jelszót regisztrációnál? Az, hogy nincs igazán megoldva a jelszavak eszközök közötti szinkronizációja?
Igen, de én úgy érzem, hogy a "time-based" rész ebben mellékes. A lényeg az újrahasznosítás megakadályozása. A lényegi különbséget abban érzem, hogy nem a felhasználót kérjük meg, hogy írjon be egy jelszót (amikor is nyilván mindig, mindenhol ugyanazt fogja megadni regisztrációnál), hanem mi generálunk számára egy szolgáltatás-specifikus titkot. A QR kódban az "otpauth://" URL szerepel, amiben van userid, secret, és a szolgáltatás weboldala. Lényegében rákényszerítjük a felhasználót, hogy minden oldalhoz külön jelszót használjon, és ezt úgy érjük el, hogy minden oldal külön generál neki secret-et. Neki nincs választása; annyit tehet, hogy amit kapott, azt elmenti a jelszókezelőjével.
Az, hogy a secret-ből aztán 30 másodpercenként más kódot származtatunk, ebből a szempontból mellékesnek tűnik.
A user hülye, ezt tudjuk. A TOTP szerintem egy jó kényszeritő eszköz, hogy a hülyeségét csökkentsük. Ha meg tényleg másik eszközön használja, az még tovább emeli a biztonságot.
Ha "csak" a tényleg egyedi, erős jelszót tudnánk kikényszeriteni - amit nem tudunk - az azért ennél kevesebb, ha viszi valami malware a böngészős jelszótárolóját, akkor visznek mindent.
"Az okoseszközök korában mi szól amellett, hogy az emberek kézzel válasszanak jelszót regisztrációnál? "
Az, hogy több milliárd NEM okoseszközt is használnak az emberek, nap-mint-nap. Teljesen természetes, hogy pl. munkahelyi gépén is be tudjon lépni a tesco webshop-ba és messze nem triviális, hogy ugyanazzal a userrel lenne belépve a böngészőjébe a munkahelyén, mint a telefonján. (már, ha egyáltalán bármivel is be van lépve a böngészőbe)
"Teljesen természetes, hogy pl. munkahelyi gépén is be tudjon lépni a tesco webshop-ba"
NEM természetes. Csak annak tekintik sokan.
NEM természetes az sem, hogy a userek ugyanazt a jelszót adják meg minden weboldalon, mégis megteszik.
És persze, eleve legyen mindenkinek külön munkahelyi mobilja, amit csak munkára használ és privát mobilja, amilyen semmilyen munkával kapcsolatos dolgot nem végez, még egy google keresést sem. Ugyanigy, otthonra a cég adjon egy külön PC-t, amiről távolról dolgozhat.
Ez mind nagyon szép, de itt most a gyakorlatról beszélünk és arról, hogy mivel lehetne a biztonságot növelni, reálisan.
"És persze, eleve legyen mindenkinek külön munkahelyi mobilja, amit csak munkára használ és privát mobilja, amilyen semmilyen munkával kapcsolatos dolgot nem végez,"
Normális esetben van MDM (mobile device management), amivel egy eszközön szétválasztható a privát és a céges identitás és a kapcsolódó adatok és alkalmazások.
"Ugyanigy, otthonra a cég adjon egy külön PC-t, amiről távolról dolgozhat."
Távmunkára normális esetben természetesen NEM használható magán eszköz...
De ugye te is érted, hogy ez kivállalatok MILLIÓINÁL nem működik és nem is fog működni. Ezekkel is kezdeni kell valamit, a sima magánemberek védelméről nem is beszélve.
A kisvállalatok millióinál is működnie kell majd, miután néhányat sz@rrá bírságolnak adatkezelési hiányosságok illetve abból eredő adatkezelési incidensek miatt. Egy cég elég, ha egyszer mexívja...
OK, biztos igy lesz.
Szerintem simán használható, ha nem tiltja szabályzat. Teljesen releváns amit írsz egy nagyvállalat esetén, ahol külső és belső audit megfelelések miatt ki van zárva a magánhasználat.
De nem tudok olyan törvényi előírást, ami tiltaná ezt a használatot alapértelmezetten. Te tudsz esetleg?
Nemhogy történyi előirás nincs, de elég csak a BYOD -ra gondolni, sok helyen nészerű.
AMikre kifejezetten komoly és szigorú policy vonatkozik normális helyen... Pl. hozhatod a saját telefonodat, de kapsz rá MDM-et, és a céges meg a privát adataid ezzel lesznek szétválasztva. (A BYOD az költséggazdák szemében nagyszerű ötlet, az ITSEC területnek meg rémálom...)
Mai napig nem láttam jó prezentációt meg live demo-t róla, h. adott MDM megoldások milyen rizikóz jelentenek Nekem, mint az endusernek, ha attól tartok h. a munkáltatóm kutakodik a személyes dolgaim között a telefonomon.
Tud bárki ilyen prezentációról?
Szkeptikus vagyok vajon ténylegesen mit látnak, kifejezetten de nem kizárólagosan az alábbiakra gondolok: híváslista (metaadat, meg a konkrét hívás lehallgatása), sms (a metaadat, és az üzenet tényleges tartalma), privát email fiókok tartalma, fájlrendszer access, fotó és videó tár, böngésző history és bookmarkok. Vagy a bónusz kérdés, h. mi a helyzet egy remote wipe-nál, mi megy a levesbe, mihez nem tud hozzányúlni egy ilyen wipe?
Kérdezném a helyi IT-t, de vagy nem tudják, vagy belső szekuriti paranoiából letagadják mire képesek tényleg (elkerülve egy munkaügyi pernél a felelősségrevonásuk lehetőségét), és takaróznak a jogi részleg által megírattatott és elfogadtatott papírokkal.
Vagy álljak neki felhúzni saját demo környezetet, Intune-t meg társait és próbáljam ki ha ebbe a demo-ba enroll-olom a telefonomat- mit tudok belőle kideríteni?
MDM beállítástól függ, hogy hogyan működik. Mivel elsődlegesen két identitás elhatárolása a cél, így az MDM kifejezetten úgy működik, hogy a két identitással keletkezett adatok semmilyen módon ne keveredjenek.
A wipe esetén mindazok az adatok, szoftverek (vagy szoftvereknek az adott identitás alá készült klónjai) illetve beállítások mennek a lecsóva, amik az MDM-es identitással kerültek a telefonra, illezve amit az MDM "tolt le" a készülékre, legyen az sw vagy beállítás.
Mondanám, hogy gugli a barátod, de ahogy látom, neked nagyon nem az :-P
A kicsiknek nincs rá pénze a nagyok meg nemigazán tudják használni.
Általában valamilyen saját fejlesztésű Tákolmapp-ot (TM) "védenek" vele, láttam már olyan, hogy a Tákolmapp mellé volt telepítve és az MDM-en app whiltelisten volt a Tákolmapp "admin" appja amin ott figyelt a Dump DB gomb. Olyat is, hogy a Tákolmapp egy "titkos" swype után feldobta az sql editor activity-t és kiköpte a tárolt API kulcsokat. Úgyhogy vannak fenntartásaim azzal kapcsolatban, hogy menne a kicsiknek, ha a nagyoknak sem igazán.
Hint: miradore - 50 device-ig van free plan, bár a tényleg jól használható feature set az a Premium verzióban van meg. (nincs a céghez/termékhez semmi közöm, csak szembe jött a multkorában)
A google a barátod random találatai pont nem érdekel ebben a témában. De nívós YT-előadást az mondtam, szóval mellélőttél.
Azt többre értékelném, ha valaki szekus-ként anonim megvallaná, mit láthat és tehet azon felül, mint ami a google-találat szerinti prospektusban be van ismerve. Szemellenzős bankinformatikusként te ezt úgy sem értheted.
Hogy most épp mivel keresem a kenyérre valót, az lényegtelen, foglalkoztam MDM bevezetéssel is, és amit láttam, az teljesen rendben volt: az elválasztás mindkét irányban korrekten működött: a személyes "profil" nem látott rá/nem volt hatással a céges profilra és viszont. De ha ennyire csak a saját szemednek akarsz hinni, akkor például az említett szoftvert kipróbálhatod, vagy utánanézhetsz a Samsung Knox -nak, mit eszköznek, mert gondolom hiába írtam, hogy korrekten működő elválasztást láttam, neked ez nem elég.
A Samsung Knox az feltételezi, hogy ami nem Samsung, azon Android alatt nem is megoldható a szétválasztott MDM? Mert Knox-a csak a Samsungnak van, más nagy Android vendor hasonló fícsörjét nem említetted (már ha a Knox-on kívül létezik ilyen más nagy vendor-tól).
Googlenak van valami zero-touch zenterprise cucca az is felhős mint a Knox csak szerintem univerzális (amint netet kap a menedzselt eszköz a play services szépen helyre rakja factory reset után is) , amit még én láttam vmware workspace one intelligent hub és az ibm-nek a MaaS360-a.
És a Mason telefon, ami elvileg hardwares védelem is lenne, de valamiért a gyártó úgy gondolta, hogy a zenterprise secure device on jó ötlet bekapcsolva hagyni az edl-t :)
Nekem tönkrement a telefonom amin a 2FA token volt. Lehetetlen megoldani egy új regisztrációnál így inkább kértem DÁP-ot.
Használj Google Authenticator-t, az simán folytatja új telefonon. Hogy ez azt jelenti e, hogy a Google hozzáfér az MFA összes faktorához, valószínűleg igen...
https://support.google.com/accounts/thread/149245119/recover-secret-key…
Pedig itt azt mondják, hogy istenbizony nem tölti fel sehova a seedet.
Értem, de mivel az új telefonra költözéskor (Samsung->Samsung) egy csomó hibám volt (nem a költözés miatt, mint utóbb kiderült, hanem a túl új Android), ezért full gyári reset után egyesével raktam fel az új alkalmazásokat. Az Authenticator miatt nem is töröltem a régi telefont, hogy amíg mindent elintézek legyen működő. Hát nem kellett. Authenticator szűz install, Google account bejelentkezés, megjelent az összes csatolt alkalmazás összes csatolt profilja és működik is.
Ezért mondják h. a yubico authenticatora annyival megbízhatóbb h. ott a seed-et beadod a kulcsnak, és onnantól az authenticator nem tárolja local-ban (bár beállítható, ha nagyon akarnád ezt...)
Google authban is van szimpla export import qr-koddal.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
A tokenben attól még ott lesz, csak épp nem tudod belőle kinyerni, mert "benne van" a totp-t számoló hardver is, ami ha kérnek tőle egy kódot, kinéz az órára, és visszaadaja az f(idő, shared secret) eredményét.
Akkor biztos erre szokta mondani zeller, hogy a banki appok egy szuperbiztonságos tárolót használnak a kulcsaikhoz, amit mezei hekker nem tud kiszedni a telóból...kivéve a google :D
A TOTP shared secret-et az alkalmazás menthető/backup-olható módon tárolja. Egyébként a Microsoft authenticator is ugyanígy működik, ott a Microsoft fiókon keresztül van költöztetési/backup lehetőség. De ha mutatsz egy totp megvalósítást, ami nem ilyen módon tárol, akkor azt fogom használni én is.
Próbálj meg feltölteni egy kliens cert/key párost a telefonodra, majd visszaolvasni/kinyerni a privát kulcsot az eszközből - az nem fog menni.
A mobilbanki alkalmazások erős azonosításra biometriát, illetve push-t használnak, illetve a deviceID-t is használják az eszköz azonosítására/hozzáférés engedélyezése során, ami a bárhol, bármilyen módon, tetszőleges példányszámban tárolt shared secret-et használáó totp-nél több szempontból is jobb.
:)
legtöbb helyen ez az "erős azonosítás", csak egy kényelmi fícsör hogy ne kelljen a 6-jegyű pin kódot használni... szóval pont annyira 'erős' mint a 6 jegyü pin, ugyanis arra bármikor lehet failback-ot forszolni.
úgy általában a bankok úgy 5-6 év lemaradással (és/vagy ahgy a PCI-DSS megköveteli) 'követik' a securty best practice-eket ;)
szrintem.
zrubi.hu
A műveletek kapcsán szerintem az auth módja is naplózásra kerül... A PCI/DSS a kártyaadatokat kezelőkre vonatkozik - nem minden bank/banki rendszer esik ennek hatálya alá - ellenben a hazai pénzintézeteknél az MNB "ajánlások" betartása az elvárt, ami több esetben szigorúbb is lehet akár...
Off topic:
Megy mar az MS Authenticatornak az, hogy Android <-> Apple kozott tudjon koltozni?
Egy ideje nem neztem, de par eve meg nem tudta.
Ha a "nem ilyen mód" alatt azt érted, hogy nem kell fiók a mentéshez, akkor azt az Aegis is tudja (meg, felteszem, még több más hasonló megvalósítás is). Kiválasztod a formátumot ({Statham}, HTML vagy TXT), be- vagy kikapcsolod a titkosított mentést, meg elvileg azt is kiválaszthatod, hogy melyik csoportokat mentse. Végül lesz egy fájlod, amit Google/MS nélkül is oda másolsz, ahova akarsz.
Azt értem rajta, hogy a telefonról a shared secret nem nyerhető ki, azaz a telefonról azt nem lehet ellopni/kimásolni. Pont az lenne a cél, hogy a secret ne legyen kimásolható... (Ahogy egy valamirevaló hwtokenből sem "jön ki", miután bele lett kalapálva...)
TPM, smartcard - mintha a mobil OS-ek találták volna fel a spanyolviaszt.
Meg hát a SCAM-ek 99%-a nem ilyen szofisztikált Mission Impossible kulcslopás, hanem egyszerűen megkérik a usert, hogy jelentkezzen be nekik.
Az exportálható-másolható 2FA secret az egy nem jó, de a semminél sokkal jobb megoldás :-/ Attól, hogy az userek hülyék nehéz (bár az MNB ezt is elvárná...) megvédeni őket, viszont amit lehet, meg kell tenni a biztonságos azonosítás érdekében...
Webauthn-nél az a nagy találmány, h. validálja a jelszókéró oldal domainjét. Így a phishing-et lebuktatja.
https://hup.hu/comment/2912426
nyilvan a gauth hozzafer a secrethez, kulonben nem tudna kodot generalni. ha meg hozzafer, akkor feltolteni is tudja. nincs ebben semmi magic hack.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Mert a TOTP szoftveresen van megvalósítva, és a secret simán fájlban van tárolva, nem pedig egy HSM-ként működő eszközben.
hat mivel az telokba nem raktak hw-s otp generatort azert kenytelenek sw-bol tolni. bar a secret mar nem fajlban van, hanem mar biztonsagos taroloban.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ha exportálható, akkor nem jó helyen van... Egy cert+key párosból a key explicite nem szedhető ki a telefonból, a TOTP secret meg igen...
csak az app tudja exportalni, elvileg mas entitas nem fer hozza a keystore-hoz.
bar tudjuk hogy a qr kod printscreenelese/lefenykepezese es kinyomtatasa backupnak az mar secure! :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Onnantól, hogy az app felolvassa megfelelő jogosultság birtokában, már "kijött" a tárolóelemból - ami erősen csökkenti a biztonságot - ellenben a rendelkezésre állást (a backup lehetősége miatt) növeli.
A QR-kódban elheyezett secret offline/offsite védett tárolása akár papírra nyomtatva teljesen jó _lehet_ ha a tárolása kellően biztonságos módon történik. (A desktopra kirakott fészbuk_2fa_kód.jpg nem az :-) ) Nálam a páncélkazettában van néhány A4-es lap, illetve lassan kerül melléjük egy yubikey is...
onnantol hogy a qr appot letoltotted es ott figyek a gep lemezen, az minden csak nem biztonsagos tarolas. bar lehet hogy a banki korokben az :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nincs 2FA app a desktop gépemen, csak a mobilomon, bankolás esetén meg push+mobil app a standard... A secret meg megy nyomtatva a páncélba :-P
az a baj hogy egy pancelt sokkal konnyebb feltorni mint akar egy 1024 bites rsa kulcsot...
Rá kell jönni, hol van, oda be kell jutni, ott meg kell találni, fel kell nyitni... Ezt elég nehéz észrevétlenül megoldani. De persze lehet azt is mondani, hogy titkosított pendrive-on qrkod_xxx.jpg fájlokban tárolva biztonságosabb - igen, biztonságosabb, de ehhez kell két pendrive...
Ugyan. Meg lehet találni azt az embert, aki 1 tábla csokiért odaadja.
Következő hülye kérdés: ha nem regisztrálok semmi másra, ezáltal gondolom a fiókom megszűnik.
Ezentúl a hivatalos dokumentumok, amik a tárhelyre érkeztek, majd újra hozza a postás tértivevénnyel? Igazából ez egy egész jó passzív ellenállás lenne a rendszerrel szemben, küldözgessék csak a leveleket, ha nekik ez jó.
Amúgy meg ahhoz képest, hogy az ügyfélkapu user/pass párosa valóban nem nevezhető XXI. századi biztonságnak, valahogy mégsem voltak tele azzal a hírek, hogy ezzel visszaéltek volna. Ellenben banki csalásról rengeteget hallani.
És pontosan mit szeretnél elérni az "ellenállásoddal"? Főleg ha te is belátod, hogy ilyen kényes adatokat, tevékenységet nyújtó rendszernél nagyon kevés egy fix név-jelszó.
Más kérdés, hogy nem nekik lesz probléma a levélben küldözgetés, hanem ismerve a posta fantasztikus szolgáltatását, te fogod irgalmatlanul megszivni, a kézbesitettnek tekintett, ellenben általad soha meg nem kapott fontos dokumentumok következményeivel.
Ja, fontos dokumentumok mint hogy megérkezett az adó 1%-om a megfelelő helyre.
A levelet valakinek ki kell nyomtatnia, postára kell adnia, stb. Ha tömegesen nem térnek át, akkor ebből keletkezik bőven plusz munkahely, amire eddig nem volt szükség (vagy el kell kezdeni dolgozni azoknak az embereknek, akik eddig nem csináltak semmit).
Én pedig nem vagyok hajlandó sem Google, sem Apple platformhoz kötni az életemet.
De amíg ott van a Linux alól is használható megoldás, addig nekem nincs bajom.
"A levelet valakinek ki kell nyomtatnia, postára kell adnia, stb. Ha tömegesen nem térnek át, akkor ebből keletkezik bőven plusz munkahely,"
Nagyjából nulla plusz munkahelyre lesz szükség - elkészül a pdf, megy automatán a nyomdába/borítékolásra és postázásra gyakorlatilag emberi kéz érintése nélkül. (A fölösleges papírpazarlásról, ami nagyon nem zöld dolog, most nem beszélve...)
A kérdésre nem válaszoltál.
Bár más is leirta, ezzel semmi gondot nem tudsz okozni, ezt nem eberek végzik, teljesen automatizált. Ha sokan kérik levélben, akkor annyi történik, hogy az adódból több pénzt fog az automatizált levélküldő nyomda kapni. 20 éve is ki tudtak küldeni többmillió embernek 30 oldalas adóbevallás iveket, bevallás idejére ütemezve.
De továbbra is mi lenne a célja a nagy ellenállásnak? Maradjon meg a gagyi webshopokhoz is kevés név-jelszó bejelentkezés az ügyfélkapuhoz?
Linux alól senki nem tiltja, hogy TOTP-t generálj és azzal lépj be ügyfélkapu+-ba.
Elsősorban azt szeretném elérni hogy se az Androidra se az iOS-re ne legyek rákényszerítve.
Másodsorban nekem ettől a telefonos "kétfaktortól" is herótom van. Kb. mindenhol más jelszót használok, ahol számít. Online fizetésnél is utálom az SMS-t, régen simán fejből tudtam az összes kártyaadatom, másodpercek alatt telefonnyomkodás nélkül is tudtam fizetni. Nem vagyok köteles mobiltelefont tartani.
De egy chipkártyás/USB stick-es kétfaktor ellen nem lenne kifogásom. Meg amúgy a PC-ben is van TPM modul, ha nagyon akarnák, gondolom azt is lehetne használni.
Mert pont ez a bajom: azt mondjátok, hogy a PC-m nem kétfaktor, de pont ennyire a telefon sem az. Ha csak egy telefonod van, azzal tudsz netbankolni, tudsz DÁP-ba jelentkezni, tudsz Packeta csomagot átvenni. Senkit nem zavar, hogy egyetlen eszköz.
Ha csak egy PC-d vagy laptopod van, azzal egyedül semmit sem tudsz csinálni. Azt őszintén szólva nem követtem, hogy a böngésző API-k hogyan állnak, hozzáférnek-e a TPM chiphez, de legrosszabb esetben egy 3rd party appal ugyanezt a biztonságot el lehetne érni.
Sőt, egy PC, de egy laptop is azért sokkal kisebb esélyedből esik ki a farzsebedből...
És még egyszer: hány olyan esetről hallottál, hogy ellopott ügyfélkapu jelszóval mittomén nemváltó műtétre jelentkeztek XY nevében az EESZT-ben. Nyilván egy-egy ember megtörése nem akkora hír, de kirívó eseteket azért biztosan közölt volna a média. A nagy hír mégis inkább a szolgáltatóktól ellopott nagymennyiségű adat szokott lenni.
"Elsősorban azt szeretném elérni hogy se az Androidra se az iOS-re ne legyek rákényszerítve."
Mert rá vagy?
És hol olvastál olyat, hogy androidra vagy ios-re akarnak kényszeriteni? A TOTP-s bejelentkezés marad, egyelőre annyi lett felvetve, hogy ha DÁP-ozol, akkor azzal tudsz belépni, mivel jóval biztonságosabb mint a TOTP. (hasonlóan ahogy a sima ügyfélkaput is tiltani lehet vagy talán már tiltják is annak, akinek TOTP-s ügyfélkapu+ -a van)
Chipkártya végülis most is van, vegyél egy yubikey-t és tedd bele az ügyfélkapus TOTP-det és probléma letudva. Annál kétfaktorabb nem is lehetne és biztonságos, mert nem lehet kiszedni belőle a kulcsot.
Passkey is lehet, hogy majd lesz a jövőben, de az még nagyon gyerekcipőben jár, az lesz majd a TPM-es megoldás. (hogy nyígtak az egész TPM ellen pár éve az "okosok")
Biztonsági rendszereket, új authentikációs módokat nem az alapján vezetünk be, hogy a kérdéses rendszer ellen tavaly hány sikeres támadás történt, hanem iparági szabványokat és javaslatokat követünk, amik a teljes világon előforduló támadások elemzésén alapulnak.
És persze nem is tudjuk, hogy hány ilyen visszaélés történt, lehet, hogy sok, lehet, hogy egy sem, de jövőre mondjuk rámozdulnak a bűnözők és csinálnának 10.000-et. És nem akkor kellene segget vakarni, hogy ja a név-jelszó már 10 éves is szar megoldás volt, keressünk akkor valami újat, hanem menjünk a probléma elébe, tudjuk, hogy könnyedén kivitelezhetőek ezek a támadások, hát akkor most vezessünk be egy jobbat.
Egyelőre hivatalos forrásból nem jött, hogy csak a DÁP maradna, de itt a HUP-on is sokan véltek rendelkezni olyan információval, hogy az Ügyfélkapu+ meg fog szűnni és csak a DÁP lesz. Tehát ez így nekem megfelel, amíg így van.
Yubikey-t megnézem, ez tetszik. A TPM-et nem mint jó példa említeném, mert az egész felépítése nem tetszik. Arra hoztam csak példának, hogy a technológia rendelkezésre áll a PC-ben is, tehát ez nem érv a telefonok kizárólagossá tételére.
Akkor most mi alapján van bevezetve? A mondat első fele és a második fele ellentmond egymásnak. Igen, nálunk a CENELEC fronton is általában van előregondolkodás is, de inkább a korábbi tapasztalatok szülik az újabb szabványokat.
Mi mondd ellent egymásnak? Azt mondtad nem tudsz róla, hogy sokan vagy bárki kihasználta volna az ügyfélkapu gyenge authentikációját. Erre mondtam, hogy mindegy, hogy volt-e kihasználva. Security evidencia sok éve, hogy a név-jelszó önmagában gyenge védelem, ezért lett több éve(!) bevezetve a TOTP, most pedig a még erősebb védelmet adó DÁP, ahol is kulcspárral azonosit, amiből a titkos kulcs hardveresen védett tárterületen van, ahonnan nem kiolvasható.
Hol látsz ellentmondást?
> az Ügyfélkapu+ meg fog szűnni és csak a DÁP lesz
en valamelyik cikkben azt olvastam, hogy akinek van DAP-ja az mar az ugyfelkapu+-t nem fogja tudni hasznalni csak a dap-ot. akinek nincs dap annak marad a +
ez jól hangzik (mármint az, hogy az "ügyfélkapu+"-t jelenleg nem tervezik erővel kivezetni)
Egy kis önreklám, véletlenül én is pont most ismerkedek a yubikey-el:
https://hup.hu/node/186684
Köszi; valóban rokon téma, kérdeztem is alatta.
Nemide
Sziasztok!
Ha már van ez a fórum, akkor gondoltam ide leírom, hogy milyen problémába ütköztem a ügyfélkapu+-ra váltás kapcsán.
Megpróbáltam igényelni az ügyfélkapu+-t, el is jutottam a folyamatban odáig, hogy beolvastam a QR kódot és az authenticator generált nekem egy kódot, ezt követően meg kellene adni újra a bejelentkezési jelszót és a 6 jegyű kódot, hogy tovább tudjak lépni a folyamatban, de a rendszer ezek megadása után azt írja, hogy a sikertelen mentés, mert hogy a felhasználónév (amit be sem kért a továbblépés előtt!) és jelszó érvénytelen. WTF? Azokkal léptembe és kezdeményeztem az igénylést... Próbáltam firefox-ból, chromiumból, PC-ről, mobil telefonról, jelszókezelőből kitöltve, kézzel beírva, minden esetben ugyanott akadt el a folyamat. Más is találkozott hasonlóval, vagy csak én vagyok ilyen "szerencsés"?
Házszám, eltéveszt. Ügyfélkapu support kukacára írj, illetve őket keresd. A magyarorszag.hu meg *.gov.hu sütiket takarítsd ki a böngésződből.
A rejtély közben megoldódott. A jelszó kezelőben két különböző címmel és két különböző URL-lel voltak elmentve a belépési adatok és ezek szerint az oldalon is különböző hivatkozások vannak, ezért hol az egyikből, hol a másikból szedte a jelszót. És nyilván a két tárolt információ közül az egyik már elavult volt. Ezért volt az, hogy amikor kézzel próbáltam beírni, akkor is a rosszat gépeltem be. Egy szó, mint száz, ez most user error volt 8-)
Nálam az volt a vicc, hogy elvileg az ügyfélkapu jelszavam 11.14-én lejárt, de simán bejelentkeztem vele, és megcsináltam a üfk+-t, kaptam is auth kódot, de csak a sima ügyfélkapuval tudtam bejelentkezni. Majd jelszó változtatás után ismét üfk+ regisztráció és onnantól már csak üfk+ működik. Esetleg cseréld le a jelszót te is és fuss neki mégegyszer.
Ma reggelre az sima ügyfélkapus login page, nem tölti ki automatikusan a felhasználónevet, és csak akkor ajánlja fel a jelszót, ha kézzel beírom a usernevet. (Firefox/Linux) Valaki tud erre megoldást?
Tegnap szembesültem vele én is. Több pluginnel se megy Windows alatt.
Én ezzel próbálkoztam, sajnos sikertelenül:
https://gist.github.com/frispete/14e8b3fc8ca6fe607724b1b94972aeca
Kézzel beírod... :-P Egyébként nem véletlenül teszik ezt...
Mire 74 éves apukám beírja a TOTP-t, addigra lejár. Értem, hogy biztonság, de vannak akikkel ez ki.aszás.
Azért hat számjegyet begépelni 30s alatt nem gondolom, hogy lehetetlen feladat -még idős korban sem. Ja, és ha jól emlékszem +/- 1 kódot elfogad... Egyébként a Google Authenticator-ban a kódtól jobbra van egy kördiagram, ami mutatja, hol tart épp az idő - ha lassan megy a szám bemásolása a böngészőbe, akkor célszerű megvárni, amíg "tele" karika lesz, és úgy elkezdeni - akkor van ugyanis 30s ideje - vagy random TOTP alkalmazásban meg azt kell megvárni, hogyváltson a szám, és akkor elkezdeni bepötyögni.
Nem kell begépelni. Rá lehet kattintani a számsorra és automatán a vágólapra kerül. Ki is írja, hogy a vágólapon van. Aztán csak egy ctrl-V kell és kész is. Mondjuk ezt nem hirdeti magáról ...
Ó, nem kell ehhez 74 évesnek lenni, meg nem kell hozzá ügyfélkapu.
Netbank weben: nem mértem meg, de érzésre még 5 perc inaktivitást sem enged meg, már kidob. Hát nem tudom, én netbankolás közben szoktam más dokumentumokat is használni; néha 2-3 PDF meg a Thunderbird is nyitva van ahhoz, hogy mindent össze tudjak nézni. (Hivatali vagy banki ügyintézésnél egyébként az ügyintézők ugyanezt csinálják, csak ők még papírra ki is írják az azonosítókat, onnan gépelik vissza, aztán ha készen vagyunk, akkor az "adatvédelem" nevében (ami ugye a rövid session timeout-ot indokolja) a cetli simán megy a normál szemetesbe, amit vagy ledarálnak, vagy nem.)
Céges rendszer negyedéves (!) értékeléshez: (már régebben történt) alapos akartam lenni, a kétheti státuszaimból (6-7 db) 45 perc alatt írtam egy összefoglalót; amikor beküldtem, akkor jött az infó, hogy ja bocs, 15 perc után a session-nek vége. Bejelentettem belső hibának, válasz: "már sokan szóltak, de az IT Security szerint ez így jó, úgyhogy így marad". A második nekifutásra 2 percet szántam, mivel nyilvánvalóvá vált, hogy valójában nem érdekli a céget, hogy az elmúlt negyedévet mivel töltöttem.
Amikor a textarea változása nem reseteli a session időzítőjét, az by design nagy el... Szóval rosszul tervezett megoldás szerintem is. Ilyenbe én is belefutottam - a második alkalommal egy szövegszerkezstőben összeraktam, amit a textarea-ba írni szerettem volna, és meg volt oldva a probléma - a másolókrém (copypaszta) teljesen jól működött :-)
Igen, másodjára mindig tudjuk mi a teendő...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Kedvencem a random akármelyik internetes fórumok, amiknèl mobilról bepötyögve a hosszú posztot, rányomok a submit-re, ekkor kibassza a hibaüzenetet h. kiléptetett és lèpjek be megint. Amikor is eltűnt a textboxból a teljes kibaszott begépelésem.
Ennek súlyosbított esete a fostalicska android és az edge / chrome faszsága, h. az OS nem képes a 8 GB RAM-ból 1-2 kilobájtot arra fenntartani, h. a textbox-ok tartalmàt aktívan megtartsa. Így mikor kilapozódik a browser, aztán meg vissza, és újratöltődik a teljes megnyitott lap, akkor ne menjen szintén a levesbe a textbox teljes tartalma.
A hab a tortán h. PC-n windows 10 alatt a "modern" gépház és az összes többi store-os app is képes ugyanezt produkálni. Azaz a settings app-ra visszaváltva (ALT+TAB) kimerevedik pár másodpercre a kép ahol hagytam, majd fehér villanás, és a főképernyőt tölti újra. Akár a calc.exe is... komolyan, saját tapasztalat alapján mondom és láttam. Szintén folytatnám a műveleteket a korábbi részeredményekkel. Kimerevedik a program képe, jön 1 rövid homokóra, 1 villanás, és üres history-val vár megint, mintha frissen indítottam volna.
Remélem a pokolban külön bugyor van annak a team-nek, aki miatt ez így lett megoldva.
Valaki, aki otthonos android OS és/vagy app fejlesztésben, okosítson ki miért ilyen balfaszul lett ez megcsinálva?
És azt ismered, amikor megirsz egy szöveget a hup-on a textboxba, beillesztesz egy linket utána, majd a linket editalni szeretnéd és dainng! Elszáll a Chrome? :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Szerintem te ott dolgozol, szivatod, aki ellenáll a DÁP-nak :D
Ráadásul új jelszónál a Firefox által generált random katyvasz szerinte nem elég erős. Hozzábiggyeszettem egy karakatert, már jó lett.
Múlt idő már, nagyon is az... De ex kollégákból vannak még arrafelé :-)
???
Annak mi köze a stabilitáshoz, hogy a jelszó hossza korlátozva van? A jelszó hosszának korlátozása miért lenne hiba?
Azt értem, hogy neked ez a korlátozás nem tetszik, győzd meg őket, hogy vagy ne legyen korlát, vagy jóval hosszabb lehessen a jelszó 30 karakternél. Engem nem fog zavarni, ha sikerrel jársz.
<narrátor> sikerrel járt.