In addition, octets may be encoded by a character triplet consisting
of the character "%" followed by the two hexadecimal digits (from
"0123456789ABCDEF") which forming the hexadecimal value of the octet.
(The characters "abcdef" may also be used in hexadecimal encodings.)
Na most a bökkenő az, hogy a Microsoftnál valaki úgy gondolta, hogy inkább a "may also" kezdetű részt implementálja, ahogy az a HttpEncoderUtility.cs 32. sorában látszik is, szemben a PHP-vel, akik eddig már nem olvasták el az RFC-t, és maradtak az egyszerűbb megoldásnál.
Többit ki lehet találni.
Szóval kérdés, hogy kit rúgjunk fejbe?
- az IETF-et, hogy miért kell olyan szabványt készítenie, amely többféleképp is értelmezhető?
- a Microsoftot, mert utálni kell élt a szabvány adta lehetőséggel?
- a PHP-t, mert nem úgy csinálta, mint a Microsoft azt egyébként is utáljuk?
- az API tervezőit, amiért erre nem gondoltak?
:)
- saxus blogja
- A hozzászóláshoz be kell jelentkezni
- 1827 megtekintés
Hozzászólások
Erre ugye még rájön egy SSL?
DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3
- A hozzászóláshoz be kell jelentkezni
> és egy hashból, ami sha1(urlencode(request) + sha1(jelszó)) formában épül fel
Ez vicc, ugye? :)
- A hozzászóláshoz be kell jelentkezni
Próbálok itt diszkrét lenni, erre jössz te :D
DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3
- A hozzászóláshoz be kell jelentkezni
Nem. Egyebkent szvsz alapvetoen nem lenne hulyeseg, hogy igy saltoljak a jelszot, csak lathatoan nem gondoltak arra, hogy az urlencodenek vannak ilyen mellekhatasai.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ezzel tobb problema is van:
- Jelszot kliensoldalon nem kell "saltolni" (ez egyebkent sem salt). Szerveroldalon, tarolasnal kell.
- Minden requesttel jelszot kuldeni? Erre valok az auth tokenek.
- Teljesen mindegy, hol, de az sha1 nem jelszo hashelesere van.
Eleve nem ertem egyebkent, hogy mi a cel ezzel a sha1(query + sha1(jelszo)) dologgal.
- A hozzászóláshoz be kell jelentkezni
A cél(ok) a következők lehetnek:
- Jelszó küldése hálózaton keresztül, mert kell valami, amivel azonosítani lehet az usert. (Most tök mindegy, hogy auth token, vagy név+jelszó páros).
- Lehetőleg mindezt anélkül, hogy az könnyen kideríthető lenne.
- Naplózható legyen a kérés olyan formában, hogy abból ne legyen triviális visszafejteni a jelszót. (Ugye, ha csak egy hash lenne vagy egy token, akkor az elég triviális lenne ellopni az egész requestet ismerve)
- Valószínűleg azért az sha1(jelszó) kerül hozzáfűzésre, mert ők is sha1-el hashelve tárolják a jelszót. (Egyébként tökmindegy mire van, rengetegen használják ezt és még mindig jobb, mint az md5 ilyen célra.)
Egyébként nekem egy picit úgy tűnik, hogy te erre csak szimplán ránéztél, viccnek minősítetted, azt azonban nem gondoltad végig, hogy mi lehetett vele a céljuk.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
-Nem egészen, mert egy tokennek általában van lejárata. Jobb esetben mire hozzájutnak, érvénytelen.
-Ez még simán bruteforce-olható.
-???
-Ha az SHA1-et küldözgeted, kb semmi értelme az egésznek. Aki ellopja, nem is kell visszafejtenie a jelszót, elég neki az sha1-es változat, amit ugyan úgy elküldhet. Ha így is tárolják, az szimpla öntökölszúrás, mert egy db szivárgás esetén minden autentikációhoz szükséges adat ott van, vissza sem kell fejteni.
+1: Így hogy ismert a saltoláshoz használt string, nem sokat nehezít a dolgon. Ennyiből tárolhatod plain text-ben is.
DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3
- A hozzászóláshoz be kell jelentkezni
Megeloztel :)
- A hozzászóláshoz be kell jelentkezni
Nyilván brute forceolható ez is, de tekintve, hogy maga az adat még mindig 3-4+ nagyságrenddel nagyobb, mint a jelszó, _kevésbé_ törhető mintha csak a jelszót küldenéd. Security téren meg szerintem még mindig ott tart a tudomány, hogy hogyan tudjuk nehezebbé és nem lehetetlenné tenni a törést.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ezert kell elfelejteni az egeszet es auth tokenezni. Azt nagysagrendekkel nehezebb torni.
Az adat meg mindegy, hogy mekkora egyebkent.
- A hozzászóláshoz be kell jelentkezni
" auth tokenezni. Azt nagysagrendekkel nehezebb torni."
Cserebe eleg ellopni es kesz, problem solved. Persze ha per-request auth token van, az mas.
- A hozzászóláshoz be kell jelentkezni
Miert, ezt nem?
- A hozzászóláshoz be kell jelentkezni
Oké token, de előtte egy post azért mehet? :)
- A hozzászóláshoz be kell jelentkezni
Hiába 3-4+ nagyságrenddel nagyobb, ha amúgy kódolatlanul is benne van a kérésben, ergo ismert, az sha1(urlencode(ismert_adat)+sha1($jelszó))-ból csak a $jelszó-t kell variálni a bruteforce-hoz.
Ettől nem tart még egy nagyságrenddel sem tovább.
DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3
- A hozzászóláshoz be kell jelentkezni
Ez igaz, ha talalsz olyan erteket a jelszonak amivel a helyes eredmenyt kapod akkor tudod, hogy az a helyes jelszo. Ez valoban gaz, de ha a jelszonak van egy nagy minimum hossza (esetleg eleve egy generalt szamsor) akkor ez is mindegy.
- A hozzászóláshoz be kell jelentkezni
Egy roundos sha1 et volam gyorsan lehet kezelni ;)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Az lehet, de akarhogy is nezem a teljes bitcoin hashrate keves lenne ehhez ha a jelszo eleg hosszu, vagy ha a tamado a sha1(jelszo)-t keresi.
- A hozzászóláshoz be kell jelentkezni
Tipukus ember altal generalt jelszo 22..28 bit kozotti entropianak mondott,
ez pick pack alatt megvan.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Még mindig jobb mint a cleartext, és mivel API-ról van szó (lehet, hogy túl optimista vagyok) remélem nem ember által választott a jelszó.
- A hozzászóláshoz be kell jelentkezni
- Rossz esetben meg nem.
- Mit akarsz bruteforce-szolni? A 160b-es szamot megtippelni az tehetseg. :)
- A tokent vegig titkos adatkent kell kezelni, egy ilyen hash-t nem.
- De nem a jelszo SHA1-et kuldozgeti, hanem a SHA1(urlencode(request) + SHA1(jelszo))-t ami allatira nem ugyanaz. Vedd eszre, hogy ez mas request eseten mas eredmenyt ad, igy a jelszo megtalalasahoz ket SHA1 preimage attack kell. Tulajdonkeppen ez egy HMAC szeru konstrukcio akar lenni, es akar biztonsagos is lehet ha a request-ben van olyan adat (pl. ido) ami kizarja a replay atack-eket.
- A hozzászóláshoz be kell jelentkezni
Persze, bár ahogy arról már szó volt, ha az egész üzenet is kikerül, akkor egyszerűbb a törés. Ellenben használható a hash egyben az üzenet ellenőrzésére, hogy ugyanazt kapta-e a vevő, mint amit a feladó akart küldeni (+auth).
Bár hozzáteszem: azt én is vitatom, hogy valóban ez lenne a legjobb megoldás.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Juhok altal valasztott jelszo salt nelkuli sha1 vagy plain taralosa a szerveren nem javalott.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
-Rossz esetben valóban
-Jelen felállásban elég a jelszót, ami lehet egy karakter is, a policy-t nem ismerjük
-Ebben az esetben azt is jó lenne
-Elég egy requestnek nekimenni, és offline is törhető
DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3
- A hozzászóláshoz be kell jelentkezni
Ne erts felre, nem csinalnek ilyet es nem is nagyon akarom vedeni ezt a megoldast, de...
> Jelen felállásban elég a jelszót, ami lehet egy karakter is, a policy-t nem ismerjük
Valoban, de nem tudod a jelszo hosszat a hash-bol, igy ha ellopsz tobb hasht mas felhasznaloktol akkor nem tudod melyiket erdemes tamadni.
> Elég egy requestnek nekimenni, és offline is törhető
Persze, de hosszu jelszo eseten ez eleg sokaig tartana. Ez mindenkeppen jobb mint a cleartext.
- A hozzászóláshoz be kell jelentkezni
Nomostan ha valamit lehet kétféle módon csinálni, akkor annál számítani kell arra, hogy kétféle módon fogják csinálni.
- A hozzászóláshoz be kell jelentkezni
Ennyi. Az API implementálója csak a munka töredékét végezte csak el.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
del
- A hozzászóláshoz be kell jelentkezni
Egyébként sem vagyok egy lúmen, de ezt most különösen nem értem. Az üzenetben nincs urlencode, csak a hash-képzésnél? Ott már minek?
- A hozzászóláshoz be kell jelentkezni
Gyakorlatilag igy serializalja a kuldendo tartalmat es ezt hasznalja a jelszonal saltolashoz.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Miért van urlencode a hash-képzés előtt? Valaki azt hitte, hogy tetszőleges bináris adatból nem lehet hash-t képezni?
Nyilván, ha az üzenetben magában is urlencode lenne, akkor nem lenne döntési helyzet, ami az üzenetben van, abból kell hash-t számolni.
- A hozzászóláshoz be kell jelentkezni
Mert a "tetszőleges bináris adat" jelen esetben a saját objektumaid lenne, ami aztán végképp programnyelv függő. Az urlencode itt csak egy serializálási forma. Lehetne helyette JSON, XML, vagy akár egy adott formátumú Excel tábla is.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
És pont itt a baj. Olyan adatból akarnak hasht számolni, amely adat egy nem egyértelmű szerializációval áll elő. Ennyi, ők a hülyék. Sem az MS, sem a PHP, sem az IETF, csak az API kitalálói. Ha bárhova egy requestben szerializált adat kell, akkor egyértelműnek kell lennie a szerializálásnak mindkét (küldő és fogadó) oldalon.
- A hozzászóláshoz be kell jelentkezni
Igen, ezt szerintem egyértelműen leírtam én is.
Azonban a probléma elkerülhető/minimalizálható lenne azzal, hogy ha
- az IETF nem csinálna olyan szabványt, amit kétféleképp is lehet értelmezni.
- a Microsoft nem a "may" kezdetű szakaszt implementálná.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
> Az IETF nem csinálna olyan szabványt, amit kétféleképp is lehet értelmezni.
Itt nem ket ertelmezesrol van szo, hanem ket szabalyos megoldas van. Egyik sem rosszabb mint a masik. Ettol ez meg nem lesz jo, hiszen a teljes implementacionak mind a kettot kezelnie kell.
> a Microsoft nem a "may" kezdetű szakaszt implementálná.
nade azert van a "may" kezdetu szakasz, mert ugy is lehet helyesen csinalni. A gond nem ezzel van, hiszen ez nem hibas viselkedes hanem azzal, hogy valaki nem figyelt erre es feltetelezte, hogy csak egy helyes megoldas van.
- A hozzászóláshoz be kell jelentkezni
Nyilván, de általában mindenkinek egyszerűbb szokott lenni az élete, ha nincsenek még "may" esetek.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem egészen értjük egymást, az urlencode egy byte*->byte* típusű függvény, a jelen problémából minden további nélkül ki lehetne hagyni.
Általános esetben az alábbi módszert lehet használni, ha adott valamilyen 'X' objektum, és 'f' szerializátor (még ha nem egyértelmű is):
X' := f(X)
Üzenet := userid + X' + HASH(X' + jelszó)
Fogadó oldalon először a hash validságát kell ellenőrizni, utána kiszámolni az f inverzét X'-re.
- A hozzászóláshoz be kell jelentkezni
A baj az, hogy az urlencode az nem egy, hanem két függvény valójában. A kliensek számára az van megadva a specifikációban valójában, hogy (f1 vagy f2 közül valamelyiket használd), az egyik kliens f1-et, a másik f2-t használja, a fogadó fél (aki meg ellenőriz), valójában f1-et akar, csak nem ezt specifikálta.
- A hozzászóláshoz be kell jelentkezni
Miért is baj? Az előbbi hozzászólásomat ha megnézed, látod, hogy a címzettnek nem kell kiszámolnia f-et (urlencode), csak f-inverzét (urldecode).
- A hozzászóláshoz be kell jelentkezni
De az nem annak a függvénynek az inverze, mint amivel f(x)-et előállították.
Ha ő f1^-1-et számol f2(x)-re, nehezen fog x kijönni eredménynek.
- A hozzászóláshoz be kell jelentkezni
De, természetesen az %c1 és %C1 ugyanarra urldecode-olódik.
- A hozzászóláshoz be kell jelentkezni
Akkor az nem inverzfüggvény.
- A hozzászóláshoz be kell jelentkezni
Persze, de valóban szükség van arra, hogy ezt is meg azt is engedjük?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem lehet, hogy körbe-körbe járunk? Ebben a konkrét esetben az urlencode/decode simán kihagyható. Az általános esetről meg fentebb írtam:
X' := f(X)
Üzenet := userid + X' + HASH(X' + jelszó)
Fogadó oldalon először a hash validságát kell ellenőrizni, utána kiszámolni az f inverzét X'-re.
Szerk (az összehasonlítás kedvéért): most ugyebár ez van:
X' := f(X)
Üzenet := userid + X + HASH(X' + jelszó)
ez tényleg csak akkor működik, ha 'f' egyértelmű, egyébként hibásan definiált a protokoll.
- A hozzászóláshoz be kell jelentkezni
Nem, az urlencode NEM egy y = f(x) függvény, mert x bemenetre lehet y1 és y2 is érvényes válasz, mert igaz az, hogy x = urldecode(y1), x = urldecode(y2).
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
4. , es nem csak ez a gyanus resz a tervben.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Szerintem mar az IETF-nel el van kurva a dolog. Minek csinal olyan szabvanyt, amit ketfelekepp is lehet ertelmezni, ha arra amugy semmilyen szukseg nincs.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Miért nem egyértelmű az RFC? Szerintem az: egyértelműen megengedi a két lehetőséget.
- A hozzászóláshoz be kell jelentkezni
Nem volt bijectivnek nevezve a fuggveny, aminek valoszinuleg tortenelmi okai is vannak.
BTW minek urlencodolni hasheles elott ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Már többször szerepelt a threadban, hogy ezt választották az adatnak a serializalasara.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Igen, de az is többször szerepelt, hogy az urlencode egy byte-sorozat --> byte-sorozat transzformáció, nem pedig egy objektum-serializátor.
- A hozzászóláshoz be kell jelentkezni
Az objektum szerializálás is bytesorozatból csinál bytesorozatot.
- A hozzászóláshoz be kell jelentkezni
Azért ez vitatható, illetve az 'objektum' értelmezésétől függ. Nem ritkaság, hogy az objektum komponensei (akik maguk is lehetnek objektumok), szerteszét vannak a memóriában. (Lehet mondjuk az illető objektum egy (pointerekkel megvalósított) bináris fa, például.)
- A hozzászóláshoz be kell jelentkezni
Szerintem eléggé egyértelművé kellett volna már válnia mindenkinek, hogy az urlencode itt arra szolgál, hogy a saját rendszered objektumait, amik "szerteszét vannak a memóriában" az adott programnyelv belső adatszerkezete szerint egy mindkét fél által ismert formátumban tárolható, továbbítható formára hozzuk. Barátok közt egyébként ezt hívják szerializációnak.
Lehetett volna Json, XML, megfelelő struktúrájú markdown vagy akár egy jól definiált PNG is, de a készítők ezt választották.
(Feltételezem azért, mert túloldalt PHP van és így egyből megkapják $_POST tömbben az adatot és nem kell a parseolásával foglalkozni csak a validálásával, de ez totálisan részletkérdés.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Igen, de igazából nem csinál ilyesmit az urlencode... egy darab byte-sorozat a bemenete, és egy darab byte-sorozat a kimenete, pl:
A B&C -> A+B%26C
- A hozzászóláshoz be kell jelentkezni
Jó, ilyen szempontból valóban nem volt pontos a megfogalmazásom. A Request ez esetben egy HTTP szabványnak megfelelő Request, példakódban a http_build_query kimenete, ami egy arraykupacot, objektumot képes a HTTP szabványnak megfelelő kulcs
=érték párok a hozni. De ne már, hogy még mindig itt tartunk.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Akkor most kb itt tartunk (az eredeti bejegyzést is számolva)?:
function Body_előállítás ($objektum, $user, $pwd) {
$eleje = 'user='.$user;
$közepe = http_build_query ($objektum);
$vége = 'hash='.SHA1($közepe.$pwd);
return $eleje.'&'.közepe.'&'.$vége;
}
- A hozzászóláshoz be kell jelentkezni
Nem egészen értem, az adattartalom az URL-ben van leégetve, és üres BODY -t POST-oltok? Jaj.
--
arch,debian,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Nem. Az adat a Bodyban megy, mint egy sima űrlap.
(Szerinted egy formot hogyan küld el a böngésző, ha nem urlencodeolva?)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
En akkor is a Javascriptet utalom. Jobban mint a PHP-t.
Igen, a PHP rosszul tervezett nyelv tele hibakkal, de legalabb nem ereznek az emberek olyan eros kenyszert write-only kod irasara, mint a Javascript nyelvi eszkoztaranak "hatasara". Ennyit engedtessek meg felhoznom a PHP vedelmeben: ritka a write-only debuggolhatatlan PHP kod.
- A hozzászóláshoz be kell jelentkezni
Tudsz mutatni olyan javascript nyelvi elemeket, amik szerinted hozzájárulnak ahhoz, hogy egy kód write-only legyen?
- A hozzászóláshoz be kell jelentkezni
Ennek a threadnek a bonyolultsaga:
http://stackoverflow.com/questions/6597493/synchronous-database-queries…
Mar onmagaban is egy notable example.
Baromi egyszeru kerdes kene hogy legyen, es minden ertelmes valasz kilometer hosszu a nyelv hulyesegei miatt.
Aztan mikor hataridore programozol nem olvasol vegig ennyit, megcsinalod az elso modszerrel ami mukodik. Akkor kodolsz szepen, ha van ra idod (altalaban nincs), vagy ha van egy lehuto, akinek van ideje rad szolni, hogy kodolj szebben, cserebe nem sok produktiv munkat csinal, azt is lassan.
Az async-ot szerintem normaliseknal igy csinaljak:
http://www.cplusplus.com/reference/thread/thread/
Vagy igy:
http://tutorials.jenkov.com/java-concurrency/creating-and-starting-thre…
- A hozzászóláshoz be kell jelentkezni
Ennek a problémának nem sok köze van a nyelvhez. Ez inkább annak a kérdésköre, hogy tudsz-e funkcionálisan gondolkozni, vagy megpróbálod ráerőltetni az imperatív megközelítést egy nem imperatív API-ra.
- A hozzászóláshoz be kell jelentkezni
"...vagy ha van egy lehuto, akinek van ideje rad szolni, hogy kodolj szebben, cserebe nem sok produktiv munkat csinal, azt is lassan."
Mert el van foglalva azzal, hogy a hipergyors kollegak olvashatatlan kodjat probalja ertelmezni.
- A hozzászóláshoz be kell jelentkezni
Ő, ha jól tudom a threading nem ugyanaz mint az async.
- A hozzászóláshoz be kell jelentkezni
Egyébként a felvetett problémára pont a nyelv ad választ.
- A hozzászóláshoz be kell jelentkezni
Az nem a nyelv hibája, ha nem érted, mi az, hogy async művelet. Meg azt, hogy hogyan lehet egyszálas runtimeban (a JS az egyszálas) async művelet, threadek nélkül.
Másrészt ma már (igazából Java 5 óta) Javaban nem igazán írunk le olyat, hogy new Thread, meg nem subclassolunk Threadet. Callable, Runnable és executorok.
Másrészt async kódból mindig lehet csinálni sync kódot, de ez megfordítva nem igaz.
- A hozzászóláshoz be kell jelentkezni
A Javasat csak odadobtam elolvasas nelkul, azt hittem a Runnable van ott leirva. ;)
Async kod meg lehet sync tok olvashatoan es legtobbek altal konnyen felfoghatoan a legtobb nyelvben. De nem JS-ben. Tobb olyan barommal talalkoztam, aki hatarozottan allitotta hogy ne SQL-ezz JS-ben, mert arra a MongoDB valo, egymas utan futtatni az SQL utasitasokat ott pedig sose lesz szep. En pedig raszantam 3 hetet hogy hogy lenne a legszebb pl egy SQL tranzakciot implementalni NodeJS-be, es arra jutottam, hogy tobb mukodo megoldast implementalva meg kellett allapitanom: "ezt nem tudom konnyen olvashatora megcsinalni". Mas nyelven ilyen kudarc sose ert, pedig hasznalok parat, obj-c es swift async protocol delegate-jeivel meg Android Asynctaskjaval az elen, amik konkretan kurva jol kitalalt async es event megoldasok.
- A hozzászóláshoz be kell jelentkezni