Ez mennyire biztonságos így jelszó nélkül?

Security-all

Egy egyszerű weboldalról van szó, ahol azonban személyes adatok is vannak tárolva.
Ezért kíváncsi lennék a véleményekre, hogy a kitalált felhasználó bejelentkeztetési folyamat mennyire biztonságos.

Infók, hogy a felesleges dolgokat kerüljük:
- A botok ellen invisible reCaptcha fog kerülni a regisztrációhoz és a bejelentkezéshez is.
- A szerver biztonsága és hogy milyen backenden fut az oldal az is fontos, de most hagyjuk, mert más téma.
- Konténerben futó friss linux és sokak által használt, folyamatosan frissített framework van használva.
- A regisztráció során a szokásos adatokon kívül meg kell adnia 2 olyan adatot is ami már létezik a rendszerben.
- Bejelentkezés során ha ugyanarra az e-mail címre X időn belül Y sikertelen kérés érkezik, akkor Z időre tiltom az adott IP-t

Ami a kérdéses pont számomra az a bejelentkezés.
Ilyenkor meg kell adnia az e-mail címét és a születési dátumát. Nincs jelszó!
Ha van ilyen e-mail címmel felhasználó és egyezik a születési dátum akkor megy egy e-mail, amiben van a beléptető link.
A link hosszú, minden bejelentkezési kérés esetén újra generált, egyedi hash-t tartalmaz. (24 óra után lejár)
Arra kattintva pedig beléptetésre kerül a felhasználó.

Tehát így 2 faktoros, viszont nincsenek jelszavak.

Az egyik gyenge pontja, hogy a felhasználók ismerhetik egymást, tehát az egyik simán tudja a másik e-mail címét és születési dátumát.
De ugye bejelentkezni nem tud vele, mert csak az e-mail-ben lévő linkre történik meg. 
Akkor van gáz, ha hozzáfér a másik gépéhez, telefonjához.

Milyen további gyenge pontjai lehetnek ennek?
Használ már valaki hasonló megoldást?

A születési év helyett mondjuk lehetne valami olyan adat bekérése amit a felhasználó mindig tudni fog,
de a munkatársa már valószínűleg nem. Pl. szülők születési dátuma

  • 1297 megtekintés

( Ar0n v | 2021. 07. 15., cs – 19:34 )

Szerkesztve: 2021. 07. 15., cs – 19:39

A link hosszú, minden bejelentkezési kérés esetén újra generált, egyedi hash-t tartalmaz. (24 óra után lejár)

Ez hogy all elo, pontosan?

Tehát így 2 faktoros, viszont nincsenek jelszavak.

Multi-factor authentication (MFA; encompassing two-factor authentication, or 2FA, along with similar terms) is an electronic authentication method in which a user is granted access to a website or application only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something only the user has), and inherence (something only the user is).

Szoval nalad a weboldalon semmi titkot nem potyog be a user (szuletesi datum nem secret), valojaban ha hozzafer valaki a levelezesehez akkor be tud lepni az oldalra. Velemenyem szerint ez igy one-factor.

Mi az oka annak, hogy nem egy meglevo megoldast hasznalsz? Mondjuk akarmilyen OTP-s megoldast (GA vagy akarmi)?

Ha nem kapja meg a levelet, mert akarmi, akkor nem tud belepni? Eleg idegesito lehet...

En user + pass + otp-t javasolnek.

Milyen további gyenge pontjai lehetnek ennek?

Hat peldaul nem tudhatod, hogy a level milyen csatornan jut el a felhasznalohoz. Titkositott vagy sem? 

A születési év helyett mondjuk lehetne valami olyan adat bekérése amit a felhasználó mindig tudni fog,
de a munkatársa már valószínűleg nem. Pl. szülők születési dátuma

Mondjuk valami ami olyat mint egy jelszo ? :)

Secret-nek hasznalni barmilyen szuletesi datumot, nem jo otlet. Gyurj ossze egy password policy-t es kerj be jelszot!

A levelezésében jó eséllyel ott lesz valahol a születési ideje, főleg ha valami cloud-os levelezést használ, ahol a dokumentumait is tárolja.

Másik oldalon viszont mindenképpen kell jelszó emlékeztető funkció, ha jelszó lenne.

Tehát, a mailbox birtokában a szolgáltatást el tudnák érni ha nincs még egy token pl.

( n.balazs v | 2021. 07. 15., cs – 20:56 )

Apró észrevételeim:

- Hogyan és mivel garantálod, hogy ugyanazzal a linkkel ne tudjon még egyszer belépni a felhasználó?
- Mi történik, ha az email késve jön meg és a felhasználó még egyszer megpróbál belépni, így 2 levelet fog majd kapni és megpróbál belépni mindkettővel? Melyik lesz érvényes?
- Ez nem 2FA. Közel sem. Gyakorlatilag a születési dátum is a felhasználói név része, mert fix. GipszJakab20000101.

Miért akarod feltalálni a spanyol viaszt? Miért nem használsz tanúsítvány alapú authentikációt?

( Raynes v | 2021. 07. 15., cs – 21:06 )

Szerintem feleslegesen próbálod a kereket újra feltalálni. Bonyolítod, de elérsz egy olyan rendszerhez, ami épp olyan komplex, mint egy jelszavas vagy 2FA rendszer, de cserében a biztonsága a 0-át verdesi. Az ilyen születési dátumok sose voltak jó ötlet, szülőké se, mert igaz, hogy az ilyeneket idegen lehet nem tudja, de ha tudja az illetőről, hogy hány éves, meg mi az e-mailje, onnantól azon az 1-2 éven belül 365 napos próbálkozással simán belép.

Legyen csak szépen hagyományos jelszó, az oldal használói meg tudják ezt kezelni. Egyedül arra figyelj, hogy jelszót ne tárolj, csak hash-t, ha leak lenne, akkor se kerüljenek bajba a felhasználók.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Kulon iparag van ra celhardverrel. Csak remenykedhet az ember, hogy ami implementalva van megoldas azt meg nem tudjak torni. A problema ott van, hogy a rendszerek 99%-ban indulas utan kb be vannak fagyasztva nem tortenik security review merthat keszen van ez mar 10 eve mi baj tortenhet?

De nem engem kell meggyozni eleg olvasgatni a torteneseket.

A nagy adatlopasoknal nem veletlenul viszik a hash-t is mert jo rajta trainingelni a feltoro algoritmust (bruteforce + dictionary)

Ha kellően erős hash, pl. SHA-256 vagy jobb, akkor max. csak brute force-szal vagy szótár alapon. De még utóbbiakat is el lehet lehetetleníteni salt-tal. MD5-öt valóban könnyű.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szerintem még hosszú évekig, de ha paranoid vagy, akkor használsz SHA-512-őt, vagy ráeresztesz valami extra megoldást, köztetes titkosítás, salt a hash előtt. Bár még nagyon sok idő szerintem, mikor már az SHA-256 nem lesz elég. Ne feledjük, itt webes belépésekről van szó, egyszerű oldalakhoz, nem kormánytitkok ezek, hogy 100+ évig kell tartson, mire megtörik. Eleve csak akkor fontos, ha volt valami leak, akkor is elég addig tartania, míg a szivárgásról a usereket nem értesítik, és le nem cseréltetik velük a jelszót határidővel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, de ez akkor van, ha hozzáférsz az e-mailfiókomhoz. Amit a kolléga ír, hogy elég csak maga az emailcím az ő rendszerében, már ha jól értem. Meg pont ezt az e-mailfiókjához van hozzáférésem trükközést szokták elkerülni 2FA megoldásokkal.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, hogy az más. Akkor viszont visszavonom, félreértettem. Ebben az esetben elég lehet csak az e-mail. Ami viszont gyengéje egy ilyen e-mailt küldözgetünk rendszernek, hogy ha nem érkezik meg valami mailtorlódás, vagy hiba miatt, vagy késve érkezik, vagy a szerver szűrője kivágja spamba, mi a fenét csinálnak? User addig nem tud belépni. Nem véletlen, hogy a mai napig az összes oldal inkább jelszót használ, és nem találják fel újra a kereket.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( gee v | 2021. 07. 15., cs – 22:30 )

Ha úgyis az email-re érkező linkkel lehet csak belépni, akkor teljesen felesleges szerintem a születési dátumot elkérni az email cím mellé. A biztonságot nem növeli, csak többet kell gépelnie a felhasználónak.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

OK, ezt el tudom fogadni. A kérdés akkor az, hogy mi idegesítőbb: kapni 2-3 emailt, mielőtt letiltja a rendszer az email címet Z percre, vagy minden alkalommal beírni a dátumot. Ha a böngésző kitölti az email cím mellett a dátumot is automatikusan, akkor az elég jó.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( buccaneers v | 2021. 07. 15., cs – 22:47 )

Rendhagyó megoldások:

- minden usernak el kell magyarázni - és még utána 10% se fogja érteni, hogyan lehet belépni (járt utat járatlanért...)

ha lassú vagy nem működik a mailserver vagy éppen a Te SMTP szervered kerül fekete listára és a google nem fogad tőled mail-t ?

Harmadik fél szolgáltatás minőségét kötni a Te rendszered használhatóságához. Nyomozni xy mail szerver miért teszi spam-be a Te leveled...

Rossz kódtáblát használó mail szerver tud fura karaktereket kavarni..

Én nem hoznám magam ilyen helyzetbe..

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

( luisex v | 2021. 07. 16., p – 08:27 )

Szia,
 A gond itt 2 dolog:

  • user szemmel gondolkozol csak, hogy neki email cím és valami személyes adat kell, authentikációt a mail hozzáférés megoldja és innentől kezdve kényelmes az élet. De támadói oldalról más a helyzet.
  • Az authentikációs pontot ebben a rendszerben rossz helyen nézed, átverve magad.

 Mi van, ha nekem am. nem Gipsz Jakab hozzáférése kell, hanem csak 1 db hozzáférés?
 1., Egy link 24 óráig él, te nem mondtál semmit a deaktiválásáról, ez alapján sejthető, hogy belépés után is tudom használni. Vagyis, csak a bejelentkezési url-t kell kitalálnom, aminek a mintája véges ( n hosszú, pattern jellegű mivel valószínűleg generált, és feltehetőleg alacsony entrópiájú, sőt, azt is tudom, hogy csak ascii karakter tud benne lenni). Ha egy darab url-t kitalálok ( a nyomok alapján végtelen próbálkozásból ), akkor már be is jutottam a rendszeredbe.
 2., Ha nekem mégis nagyon-nagyon Gipsz Jakab accountja kell, akkor megtudom a születésidátumát, és mitm behallgatok a levelezési forgalmadba - majd elkapom a linket, és bent vagyok.

 A második probléma összesen, hogy te a felhasználó+születést autentikációnak veszed, pedig nem az. Az csak legenerál egy darab linket és tokent hozzá ( authorizál belépésre ), a tényleges authentikáció a linkre kattintva történik. Így innentől kezdve egy támadónak erre a linkre kell csak fókuszálnia, minden más mellékes.
 Arról nem is beszélve, hogy a usernek nem lesz kényelmes minden alkalommal ( bárhol is van ) belépnie a mail fiókjába, hogy a linket elérje. Tegyük fel, internet kávézóban el akarja érni a tartalmat, idegen gépeken, ki tudja milyen SWk társaságában, nem biztos, hogy hajlandó lesz a linkért belépni a mail fiókjába.
 A másik oldal, ha könnyen beírható linket csinálsz, vagy áttérsz one-time-pw módszerre  - tekintve a userek panaszkodnak, hogy a link kényelmetlen - akkor már abszolút dobod az entrópiát.
 Amúgy, attól, hogy a link hosszú, még nem bonyolult. Ez egy téveszme. Attól, hogy szavakat raksz a linkbe szótárból pl, hatalmas mértékben megugrik a link hosszú, de az entrópia ha valaki meglátja ezt a mintát, elég durván leesik.
 Ugyanez kialakulhat n db random karakterrel is, mivel mintázat fedezhető fel. Neked garantált entrópia kell ebben az esetben, ami meg megnövelheti a link generálás költségét drasztikusan - persze ha 100 userre tervezel csak, ez elhanyagolható költség.
 Üdv,
LuiseX

( rascy | 2021. 07. 16., p – 09:13 )

Köszönöm a hozzászólásokat és a kérdéseket, pont ilyenekre volt szükségem.

Nem akarom feltalálni a spanyol viaszt, csak a sima e-mail cím és jelszó beléptetés helyett 1-el biztonságosabbat szeretnék alkalmazni
úgy hogy a gyenge jelszavak ne jelentsenek kockázatot, de ne is kelljen cetlire felírnia, mert elfelejtené.
A lenti lista alapján azt gondolom jobb valamivel, de lehet tévedek.

"Ez hogy all elo, pontosan?"
- random string + unique id (ez nem JWT token, de a sikeres belépés után azt kap, ami x ideig megőrzésre kerül a böngészőben)

"Mi az oka annak, hogy nem egy meglevo megoldast hasznalsz?"
- nem használom, és ilyen formában biztos nem is fogom :) 

"Ha nem kapja meg a levelet, mert akarmi, akkor nem tud belepni?"
- igen ez így lenne, de több nagyobb cégnél is e-mail-es a második faktor és ott is ugyanez előfordulhat

"Hogyan és mivel garantálod, hogy ugyanazzal a linkkel ne tudjon még egyszer belépni a felhasználó?"
- a belépéssel azonnal törlődik az adatbázisból az egyedi random string + unique id

"Mi történik, ha az email késve jön meg és a felhasználó még egyszer megpróbál belépni, így 2 levelet fog majd kapni és megpróbál belépni mindkettővel? Melyik lesz érvényes?"
- mindig az utolsó és igen ezzel már nekem is van tapasztalatom (regisztrációt aktiváló linkek esetében) hogy nem mindig értik 

Ha az e-mailben nem egy link menne csak egy 6 számjegyű kód? (OTP)
Bár az e-mail feladójából általában ki lehet deríteni, hogy milyen oldalhoz tartozik, de "hacker" akkor sem tudná hová beírni az oldalon, mert azt az oldalt nem éri el ahol be kellene ezt írni a bejelentkezéshez.
Viszont ha a levelezést feltörik vagy minden e-mailt elkapnak akkor az erős jelszó sem ér sokat, hiszen kérnek újat.

Ha a bejelentkezési folyamatokat hasonlítom össze, akkor biztonság szempontjából ez a sorrend helyes?
Tehát a megoldásom valamivel biztonságosabb mintha csak e-mail és 8 karakteres jelszó páros lenne?
Viszont ha erős jelszavakat kényszerítek ki, akkor már az jobb?
(a próbálkozásokat mindegyik esetben letiltaná a rendszer x ideig)
(erős jelszó = 10+ karakter, kis- és nagybetű, szám, és zxcvbn password strength meter használata)
(gyenge jelszó = 8+ karakter, kis- és nagybetű, szám, de pl. "Jozsi123" engedve van)

1. email és jelszó megadása (erős jelszó*) + applikációban megjelenő OTP beírása az oldalon
2. email és jelszó megadása (erős jelszó*) + SMS-ben érkező OTP beírása az oldalon
3. email és jelszó megadása (erős jelszó*) + email-ben érkező OTP beírása az oldalon
4. email és évszám (vagy valami) megadása + email-ben érkező kód beírása az oldalon
5. email megadása + email-ben érkező kód beírása az oldalon
6. email és jelszó megadása (erős jelszó*) + nincs OTP
7. email megadása + email-ben érkező linkre kattintás
8. email és jelszó megadása (gyenge jelszó*)  + nincs OTP

Lehet tényleg túlságosan rápörögtem az egészre :D

"Mi az oka annak, hogy nem egy meglevo megoldast hasznalsz?"
- nem használom, és ilyen formában biztos nem is fogom :) 

Nem tudom mit jelent az ilyen forma, de szvsz egy OTP-s megoldas mar eleg jo. Persze lehet tovabb fokozni, kerdes, hogy mennyi penz van ra...

"Ha nem kapja meg a levelet, mert akarmi, akkor nem tud belepni?"
- igen ez így lenne, de több nagyobb cégnél is e-mail-es a második faktor és ott is ugyanez előfordulhat

Nagyobb. Ha jol sejtem te nem egy Steam vagy :) Kepzeld mi tortenne, ha egyszer blokkolnak a Steam leveleit? Pl. MS siman megcsinal olyat, hogy egy teljes tartomanyt blokkol es napok amig sikerul leszedetni a sajat cimedet a listarol.

Epp nemreg meselte ismeros, az egyik COVID tesztes ceg ^^ emiatt nem tudott levelezni, gyorsan megoldottak, de ez csak nyug es nem 100%-ban rajtad mulik.

Viszont ha erős jelszavakat kényszerítek ki, akkor már az jobb?

Igen!

Ezen felul ahogy irtam, nem tudhatod, hogy az email a nap vegen hogyan jut el a userhez (esetelg titkositatlan csatornan) vagy mar hozzafernek a levelezesehez.

En az elsot javasolnam.

Lehet tényleg túlságosan rápörögtem az egészre :D

Nem! Barcsak mas is igy tenne...

Epp nemreg meselte ismeros, az egyik COVID tesztes ceg ^^ emiatt nem tudott levelezni, gyorsan megoldottak, de ez csak nyug es nem 100%-ban rajtad mulik.

Ezert volt az, hogy amikor rakerdeztek cegnel, hogy kellene rendes ceges levelezes (ami addig egy postfix alias lista volt), akkor kozoltem, hogy a sajat megoldast lehetoleg felejtsuk el, mert tobb veszodes, mint amennyi haszon. Google/Microsoft/Amazon, es akkor mar egesz jo eselyunk van arra, hogy nem kerulunk spam- / tiltolistara, valamint nem nekunk kell szivni egy 40 eve foltozgatott protokol security es egyeb cuccaival (startTLS, reverse DNS, MX, helo valasz, DKIM, SPF, port szures, antivir, spam filtering, relaying es egyeb authentikacio/authorizacio beallitasa, backup, user management, webmail, POP3/IMAP, stb.).

Ha a bejelentkezési folyamatokat hasonlítom össze, akkor biztonság szempontjából ez a sorrend helyes?

Nem. Az 5., a 7. és a 8. egyenértékű: e-mail cím és ismeretlen erősségű jelszót kell hozzá tudni.

Sőt, nem, az 5. és 7. még rosszabb, mint a 8., mert az e-mail messze nem secure csatorna.

mert az e-mail messze nem secure csatorna.

Ez alapján akkor az 1. és 2. az amit nem lehet elkapni, mert applikáció és sms forgalmának figyelése jóval nehezebb.
Így viszont mindenki aki ez alatti szintűt használ jobb lenne ha cserélné?
 

"5. és 7. még rosszabb, mint a 8"

Ezt értem, hiszen a 8-as esetben nincs e-mail amit el tudnának kapni. Így csak kb. az oldalon tudnak próbálgatni.
Kivéve ha kérnek egy elfelejtett jelszós emailt és azt elkapják.
 

szvsz az emailben küldün klinkeket típusú megoldás azért is gázos, mert feltételezi hogy a (l)user ugyan azon az eszközön képes és hajlandó is belépni a saját email fiokjába és a te szolgáltatásodban egyszerre.

 

Én biztosan nem átlagos felhsaználó vagyok, emiatt nálam ezek szinte soha nem esnek egybe.

 

szóval az OTP kód küldése emailban vagy sms-ben az még okés, mert mondjuk a telefonján olvassa a leveleit, egy random böngésző gépen pedig beírja a kódot, és mindneki örül.

 

De ahogy többen is írták:

a valós megoldás az a hagyományos jelszó + valamelyik nagy OTP (soft) token.

(azt megteheted, hogy mondjuk egy belépés után x ideig elég egy süti megléte is, nem kell minden alkalommal az OTP)

És akkor valóban lesz kétfaktoros authentikációd...

 

szerintem.

zrubi.hu

Itt az a gond, hogy vagy sajatot csinalsz, es kotelezed a regisztraciora, vagy tobbet is be kell csatornaznod, es vagy diszkriminalsz (a.k.a. disclaimerbe kiirod, hogy az oldal csak adott account meglete eseten hasznalhato), vagy adsz egy alternativ lehetoseget azoknak, akiknek egyik sincs/nem akarnak.

Szerintem is ez a helyes, nem kell password-el bajlodnod. Ha megse sso fele akarsz haladni akkor hagyd a sajat algoritmust, biztos hogy nem tudsz annal jobbat kitalani mint akinek ez a szakmaja:

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_She…

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_S…

Ahogy beleasod magad es szepen minden leimplementalsz amit itt tanacsolnak akkor rajossz, hogy jobb az sso es ez legyen mas problemaja. ha megszakadsz sem tudod megkozeleiteni azt a biztonsagot amit ok nyujtanak.

( _Franko_ v | 2021. 07. 17., szo – 12:48 )

Szerkesztve: 2021. 07. 17., szo – 12:48

Ilyenkor meg kell adnia az e-mail címét és a születési dátumát. Nincs jelszó! [...] De ugye bejelentkezni nem tud vele, mert csak az e-mail-ben lévő linkre történik meg. Akkor van gáz, ha hozzáfér a másik gépéhez, telefonjához.

Ez nagyjából annyi, mintha minden egyes alkalommal jelszóemlékeztetővel lépne be a legális felhasználó és a "támadó" is: ha viszont valaki hozzáfér a levelezésemhez, akkor bármikor képes elfelejtett jelszó feature használatával új jelszót kérni, ez így nem gyengébb, mint bármelyik 1FA azonosítás egy kis kitérővel, de ez így nem 2FA.

https://iotguru.cloud

( rascy | 2021. 09. 07., k – 15:27 )

Nos, úgy látszik más is (wolt.com) elkezdte használni ezt a "jelszómentes" beléptetést. 
Ami persze jelszavas, csak egyszer használatos.

Szia! Bemutatkozik a jelszómentes belépés ✨
Örömmel osztjuk meg veled a hírt, hogy teljesen jelszómentesek leszünk.
A továbbiakban nem lesz szükséged jelszóra, mert ezentúl minden alkalommal egyszer használatos linket küldünk neked e-mailben a wolt.com-ra történő belépéshez.

Megtehetik, hisz a google-t hasznaljak a leveleik kuldesehez. Pl. sajat SMTP-vel nem mernem ezt bevezetni.

Fontos figyelembe venni, hogy milyen adatokhoz ferhetnek hozza. Egy bank sose hasznalna ilyet.

Nem tudhatod, hogy a level milyen csatornan es hogyan jut el a cimzetthez. Ha interceptalva van menet kozben a level, akkor mi az a kar ami keletkezhet?

Itt gondolom max rendelnek a nevemben par hambit, big deal amugy is tudnak regisztalni a nevemben egy accountot...

A te esetedben mi a legnagyobb kar ami keletkezhet ha valaki hozzafer egy user accountjahoz?

( uid_720 | 2021. 09. 07., k – 17:10 )

Szerkesztve: 2021. 09. 07., k – 17:10

Ha valami ilyesmit használsz, kb. akármivel autentikálhatod a júzert.

Ahogy már többen is megírták, érdemes valami iparági szabványos megoldást használni.