ugrás a tartalomhoz

Jelszó

Hidvégi Gábor · 2019. Jan. 12. (Szo), 09.42
A következő két karakterlánc közül:

a.) "TQmfz:aVLzMJ6.*{"
b.) "Az nem lehet, hogy annyi szív hiába onta vért!"

melyik a jobb jelszó? Miért?

(Az elsőt a Strong Random Password Generator segítségével állítottam elő.)
 
1

Beszélgetni akarsz róla? Vagy

mind1 valami név · 2019. Jan. 12. (Szo), 10.19
Beszélgetni akarsz róla? Vagy tényleg nem tudod?
Egyébként a második az ékezetek miatt annyira nem nyerő, szóval ebből a szempontból az első.
Ha azt nézed, hogy brute force segítségével mennyi idő visszafejteni egyiket vagy másikat, akkor a második.
A gond ott kezdődik, hogy állítólag lassan elkészülnek az első ú.n. kvantum számítógépek, amik az ilyen támadásokat (feltéve, hogy megvan a hashelt jelszófájl) alaposan meggyorsítják.
Bocs, nagyon reggel van még... :)

zmt,Yivaat,Sniu"1tg4t.
Ez hogy tetszik? Még meg is lehet jegyezni, ha nagyon akarom :)
2

Ékezet

Hidvégi Gábor · 2019. Jan. 12. (Szo), 12.17
Mi a gond az ékezetekkel?
3

Nekem anno azt tanították,

mind1 valami név · 2019. Jan. 12. (Szo), 12.26
Nekem anno azt tanították, hogy a különböző kliensek esetlegesen eltérő charset-je, kódolása miatt nem egészséges a használatuk jelszavakban, mert kínos meglepetéseket okozhat, ha egyik helyen windows, másik helyen meg pl linux van a kliens alatt (és nem feltétlenül böngésző a kliens)
4

UTF8

Hidvégi Gábor · 2019. Jan. 12. (Szo), 12.30
Hát, az az ámítástechnika szégyene, hogy a huszonegyedik századra ezt még nem oldották meg, de arra van erőforrás, hogy az Unicode-ba minden szart beletegyenek.
5

Nem az a gond, hogy nincs

BlaZe · 2019. Jan. 12. (Szo), 14.54
Nem az a gond, hogy nincs megoldva, hanem hogy kerülhetsz olyan gép elé, ahol pl nincs ékezet. Akkor hogy lépsz be? Ezért nem szokták azonosítókba, jelszavakba ajánlani. Az manapság már elég alap kéne legyen, hogy egy UTF-8 stb gond nélkül menjen.

Lehetne mondani, hogy mostantól minden UTF-8, vagy bármi, csak akkor figyelemmel kell lenni a helyfoglalásra, azzal, hogy 1 karakter nem biztos, hogy elfér 1 byte-on stb. Így ha pl egy magyar kódolású DB-be szeretne valaki kínai karakterekkel regisztrálni, ott lesznek gondok... Oracle esetén meg pl megadható, hogy a szöveges mező mérete byte-ban, vagy karakterben értendő.

Amúgy valóban a hosszú, könnyen megjegyezhető jelszavakat szokás ajánlani. Szemben a legyen benne mindenféle kriksz-kraksz jelszavakkal.
6

Nem tudom, manapság mennyire

mind1 valami név · 2019. Jan. 12. (Szo), 15.00
Nem tudom, manapság mennyire állt át mindenki az UTF-8-ra, de amikor engem ez élesben érintett, akkor bizony nem volt mindegy, hogy milyen gépről/terminálról próbálsz ékezetet használni... :)
18

Billentyűzet

Hidvégi Gábor · 2019. Jan. 12. (Szo), 22.12
Linuxon és Windowson is lehet telepíteni virtuális billentyűzetet. Persze, van olyan, ahol ezt nem lehet megoldani, de a többséget ez nem érinti, például engem sem.
19

Jelenleg engem se. De vannak

BlaZe · 2019. Jan. 12. (Szo), 22.42
Jelenleg engem se. De vannak pl munkahelyek, ahol semmit nem tudsz telepíteni. A nagyobb cégeknél jellemzően központosított az ilyesmi, és ott nem teheted ezt meg. Tehát azért mégis elég sok embert érint.
7

Ma már: miért ne?

Pepita · 2019. Jan. 12. (Szo), 16.36
A kliens szoftvernek kell tudnia a megfelelő kiszolgálást, ha több oprendszer alá is elérhető a kliens (és nem böngésző), akkor is a fejlesztő dolga, hogy tudja kezelni az ékezeteket. Ha jelszóban nem lehet, akkor más szövegben sem, ami azért elég gáz lenne...
Tárolásba meg nem számít, feltéve ha nem plain/text mented a jelszavakat. :)
8

Tárolásba meg nem számít,

BlaZe · 2019. Jan. 12. (Szo), 16.49
Tárolásba meg nem számít, feltéve ha nem plain/text mented a jelszavakat. :)
Jelszónál persze nem. Jelszónál csak az számít, hogy mit számolsz belőle. Azonosítónál viszont számíthat.

Ha jelszóban nem lehet, akkor más szövegben sem, ami azért elég gáz lenne...
Valóban. Viszont bejelentkezni külföldről ékezetes jelszóval jó programot ígér :)
9

Ha szempont az is,

Pepita · 2019. Jan. 12. (Szo), 17.04
hogy meg tudod-e jegyezni, akkor egyértelműen a második.
Mondjuk értelmes mondatoknál is jobb az, ami nem idézet, de talán az még nem annyira játszik.
Visszafejteni nyilván a hosszabbat nehezebb, de ha már kiderül, hogy van benne space, és közte szavak, akkor hamar el tud fogyni ez az előny.
Az elsőhöz viszont használni kell valami 3. féltől származó jelszókezelőt és / vagy fel kell lennie írva valahova - szóval abban is van plusz veszélyforrás a visszafejtésen kívül.
Ha lehet azt válaszolni, akkor leginkább ezekből mindegy, hogy melyik, de legyen utána egy 2nd factor is, ami mondjuk egy regisztrált auth mobil app, nem sms / email. :)
10

Hogy derülhet ki, hogy vannak

mind1 valami név · 2019. Jan. 12. (Szo), 17.18
Hogy derülhet ki, hogy vannak benne szóközök, amennyiben nem egy alapos elemzésnek alávetett célpont az áldozat, hanem egy ismeretlen ember jelszava? Tudtommal olyan csak filmeken van, hogy a nagy hacker karakterenként fejti vissza percek alatt a password-öket...
11

dictionary

Pepita · 2019. Jan. 12. (Szo), 18.03
Se a nagy hackert nem ismerem, se a sötét oldalt. :-D
Olyat olvastam - és nem tartom lehetetlennek -, hogy ha sok jelszó hash kerül az illetéktelen kezekbe (pl a db-t sikerült kidumpolni valahogy), akkor van valami szótárazós megoldás is, de konkrétumot nem írtak (gondolom nem véletlenül), és nem is igazán foglalkoztat engem annyira.
Ha jól emlékszem, valami olyasmi a lényege, hogy miközben gyártják a csilliónyi próba-hash-t, valamennyi eredményt mentenek is (ha van), és ez alapján okosodik tovább a találgató rendszer. De a konkrét matekra nem emlékszem, de valószínű, hogy nem is írták.

Én még mindig a másik oldalon állok, úgyhogy inkább arra igyekszem fejlődni, hogy olyan megoldásokat használjak, amikkel egy (vagy többezer) hash birtokában sem könnyű mit kezdeni, függetlenül attól, hogy mi a mögötte lévő jelszó. (Nyilván nem lehet teljesen független, de értsd jól.)
Lehet, hogy nem éri meg, de én ezen az oldalon alszom nyugodtan. :-D
12

A dictionary attack az kb.

mind1 valami név · 2019. Jan. 12. (Szo), 18.17
A dictionary attack az kb. annyit jelent (hacsak nem én emlékszem rosszul), hogy adott egy óriási adathalmaz, ami ismert jelszavakat és a hozzájuk tartozó hash-eket tartalmazza. Ha megvan a kódolt jelszó adatbázis és rendelkezel egy ilyen listával (szivárványtábla/rainbow table néven lehet rákeresni arra, hogy mi ez pontosan), akkor a lenyúlt hash-t meg tudod keresni ebben a táblázatban és abból már tudhatod, hogy az milyen jelszóhoz tartozik.
Elvileg ez ellen véd valamelyest az ú.n. sózás, amikor a tárolás előtt még hozzácsapnak a tényleges jelszóhoz valami random stringet, akár jelszavanként mást. Ezt a "sót" olvasható formában szokás tárolni a jelszó hash mellett (lásd pl. crypt függvény paraméterei),.
Illetve amennyire tudom, a többszörös hash-elés (tehát amikor a már kész hash-t újra átküldöd a kódoló függvényen többször is) is ilyen céllal szokott történni.
Így a rendszer valamelyest védve van attól, hogy brute force nélkül hozzájusson illetéktelen a jelszavakhoz.

Olyanról nem tudok, hogy részeredmény is lenne pl. brute force próbálkozás közben, de lehet, hogy én tudom rosszul.

Nagy vonalakban. Persze a védelemhez az sem árt, ha x próbálkozás után egy időre vagy végleg letiltják a usert, hogy találgatással se lehessen bejutni.
13

Ezt így nem egészen értem

Pepita · 2019. Jan. 12. (Szo), 19.10
adott egy óriási adathalmaz, ami ismert jelszavakat és a hozzájuk tartozó hash-eket tartalmazza
Ez honnan van? Ki csinálta?
Jó, mondjuk ha feltételezzük, hogy nincs se sózás, se n > 1 -szeri hashelés, akkor akár én generáltam. De ez így még mindig túl egyszerűnek tűnik, plusz régen rossz, ha a fenti két feltételből egy is teljesül.
A gyakorlatban pedig inkább az szokott történni (pl yahoo pár éve ezt nyilatkozta), hogy valamilyen úton módon lenyúlják a user táblát, aztán ezzel próbálnak kezdeni valamit.

- Sózás: én ma azt mondanám, hogy több sót kell használni. Van olyan, ami valamilyen egyébként kötelező (NOT NULL) adat, aminek az oszlopneve nem feltétlenül "salt", hanem (mondjuk) username, nickname, stb, de valós adat (lehetőleg több is). Plusz mindenképp van legalább 1 fix só, ami nincs a db-ben, hanem valahol a forráskódban / configban, és csak az ismeri, aki a fájlokhoz hozzáférhet.
- Hash: mindenképp többszörös, közben is sózva, és véletlenül sem tartalmazhatja a db a kódolási technikát, darabszámokat, ez csak a szoftver része lehet. (És értelmes hash fv használni, pl ?crypt.)
- Védelem: amennyiben nem ismert keresőbot és nincs session-e ("új" látogató), akkor eleve a request-ek is időkorlátosak azonos IP-ről. Ha olyan az alkalmazás, hogy csak autentikált user használhatja, akkor további korlát, hogy amíg nincs auth, addig csak login kérés jöhet. Erre jön rá, hogy x időn belül csak y db login kérés jöhet ugyanonnan. Persze lehet ezt variálni a végtelenségig, de ez az alap. A túl sok próbálkozást user helyett én jobb szeretem IP címhez kötni, mert hamar megteheti, hogy userenként mondjuk csak 2-t postol, de többezer userrel..
14

Honnan? Darkweb... leginkább.

mind1 valami név · 2019. Jan. 12. (Szo), 19.19
Honnan? Darkweb... leginkább.
Rainbow table olvasnivaló: https://en.wikipedia.org/wiki/Rainbow_table
A többiről inkább kérdezz valaki hozzáértőt, mert én csak felszínesen foglalkoztam ezekkel a dolgokkal, de az általad felvetett dolgok egy része kb. felesleges (van rá valami szakkifejezés, hogy az eltitkolt dolgokat védelemnek hisszük, de most nem ugrik be)
A kódolási technika és a salt simán benne hagyható a hash-ben, eleve így is szokás tárolni pl. a crypt függvény használatakor:
$id$salt$encrypted - az id a kódoláshoz használt algoritmust jelzi.
23

Na ugye :)

Pepita · 2019. Jan. 14. (H), 10.36
az id a kódoláshoz használt algoritmust jelzi

De véletlenül sem azt írja le, hogy hányszor és hogyan lett sózva - hashelve. Ugyanilyen okból nem tesszük a fix sót se db-be, feltéve ha van.
Egy id vagy akár token semmit nem mond a hackernek ezekről, legfeljebb azt, hogy melyik hash fv volt az "elkövető" (pl bcrypt, sha_xxx, stb), de azt se feltétlenül.
Nem hiszem védelemnek az eltitkolt dolgokat, pusztán követem azt az ajánlást, hogy minél több felől kell összeszedni a szükséges információt a töréshez, annál több a munkaigénye..
Ha nem elég a db-t megszerezni, kell a storage is, máris két szervert kell kinyitni.
Persze ezt nem olyan egyszerű elérni, egyetlen fix só áthelyezése nem oldja meg.
26

Szerintem ennek fuss neki

mind1 valami név · 2019. Jan. 14. (H), 11.15
Szerintem ennek fuss neki még1x!
Az id megmondja a hash algoritmust, mögött meg ott a "só", amit használtak az adott hash-hez. Az valóban nincs ott, hogy hányszor lett hashelve (aminek én sok értelmét egyébként sem látom, de ez az én bajom)
27

Ja igen, bocs

Pepita · 2019. Jan. 14. (H), 11.27
Hát, ha csak ez az egyetlen só, így nekem egyáltalán nem szimpi. Ha megszerzik a db-t, szerintem hamar megfejtik, pláne ha csak egyszer lett kódolva (pont az az értelme a többszörinek, hogy hatványozza a lehetőségek számát -> még nagyobb kapacitás kell brute force-hoz is).
28

Mondjuk nem md5-öt kell

mind1 valami név · 2019. Jan. 14. (H), 11.44
Mondjuk nem md5-öt kell hashnálni ;)
A komolyabbakat a mai eszközökkel elég reménytelen visszafejteni.
30

- Sózás: én ma azt mondanám,

MadBence · 2019. Jan. 14. (H), 13.27
- Sózás: én ma azt mondanám, hogy több sót kell használni. Van olyan, ami valamilyen egyébként kötelező (NOT NULL) adat, aminek az oszlopneve nem feltétlenül "salt", hanem (mondjuk) username, nickname, stb, de valós adat (lehetőleg több is). Plusz mindenképp van legalább 1 fix só, ami nincs a db-ben, hanem valahol a forráskódban / configban, és csak az ismeri, aki a fájlokhoz hozzáférhet.

A so akkor jo, ha egy teljesen random, hosszu, egyedi ertek. Nem kell rejtegetni, folosleges titkositani. Akar oda is adhatod a juzernek. Ha egy tamado hozzafer az adatbazisodhoz, nyugodtan feltetelezheted, hogy a teljes forraskodhoz, barmihez hozzaferese van, tok folosleges rejtegetni ezt az erteket, nem arra szolgal, hogy biztonsagosabb legyen a jelszo (a tamado nem fogja "nehezebben" kitalalni a jelszot). A so a szivarvanytablak ellen van, ami a tamadonak egy time-memory trade-off (szivarvanytablakkal szamitasi idot sporolsz meg tarhelyert cserebe)
- Hash: mindenképp többszörös, közben is sózva, és véletlenül sem tartalmazhatja a db a kódolási technikát, darabszámokat, ez csak a szoftver része lehet. (És értelmes hash fv használni, pl ?crypt.)

Ne talald fel a kereket. Hasznalj bcrypt/scrypt/pbkdf2/stb-t, konfigurald ugy, hogy a hasheles kelloen lassu legyen (mar ha akar csak 1 szazad masodpercig tart egy hash eloallitasa, egy tamadonak eselye sincs kitalalni). Ne hasznalj gyors hasheket (md5, sha1, sha256, stb), mert nem erre valoak.
15

Én a másodikban számokra

inf · 2019. Jan. 12. (Szo), 19.20
Én a másodikban számokra cserélném az ékezetes magánhangzókat: "Az nem lehet, hogy annyi sz1v hi4ba onta v3rt!". Aztán akkor kompatibilis angol billentyűzettel is, meg utf-8 problémák sincsenek, meg obfuszkálva is van egy kicsit. Bár meg lehet úgy írni a rendszert, hogy automatikusan alakítsa át az ékezetes karaktereket mielőtt kipróbálná a jelszót.

Erősségre mindkettő elég erős, viszont a második dictionary attack-re lehet, hogy sebezhető. Mindkettőnél előfordulhat, hogy már bent van valamelyik jelszó adatbázisban, szóval bármelyik lehet törhető, ha már egyszer használtuk és ellopták. Ezért érdemes mindenhova egyedi jelszót csinálni és bizonyos időközönként cserélni őket. Nekem azt hiszem a LinkedIn jelszavamat lopták el, legalábbis talán 1 éve küldtek levelet, hogy cseréljem, mert kompromittálódott a rendszerük.
16

linkedin

mind1 valami név · 2019. Jan. 12. (Szo), 20.00
17

Azért kemény, hogy itt a 21.

inf · 2019. Jan. 12. (Szo), 21.59
Azért kemény, hogy itt a 21. század, mégsem használnak salt-ot. Amúgy sem használom sokat a LinkedIn accomat, ezek után elgondolkodok, hogy jobban járok, ha törlöm inkább.
20

Eloszor definialni kene, mit

MadBence · 2019. Jan. 14. (H), 00.31
Eloszor definialni kene, mit ertunk jobb alatt.



Mindket jelszoval lehetnek problemak:

  • A weboldal nem enged meg tul hosszu jelszot (2)
  • A weboldal nem enged meg ekezetes karaktereket a jelszoban (2)
  • A weboldal nem enged meg specialis karaktereket a jelszoban (1)
  • A jelszo nem felel meg a weboldal sajat jelszo-szabalyainak (1, 2)
  • A jelszo nehezen gepelheto be angol billentyuzeten (2)
  • A jelszo nehezen megjegyezheto (1)


Most nem celom itelkezni, hogy ezek kozul melyik teljesen idiota limitacio.

Alapvetoen a josag inkabb fugg attol, hogy hol akarod hasznalni a jelszot.

En speciel kb 12 karakteres random jelszavakat generalok, es jelszokezelo programmal managelem oket, igy a jelszavaim tobbsegevel sosem talalkozom, nem kell oket begepelnem.
21

Nekem ami kifejezetten

inf · 2019. Jan. 14. (H), 03.40
Nekem ami kifejezetten furcsa, hogy a netbankos rendszerek nem engednek hosszú jelszót. Az MKB-nál régen azt hiszem 14 karakter volt, pár éve tolták ki 20 körülre, a Paypal is csak 20 karaktert enged és azt hiszem szóköz nem is lehet benne. Pont ahol fontos lenne a hosszú jelszó, ott akadályozzák a használatát...

Én annyira nem bízok a jelszó kezelőkben, a tucat jelszókat jegyeztetem csak meg velük, pl a weblaborosat, ahol nem para, ha feltörik, mert max írnak a fórumba valami hülyeséget. Azok a jelszók meg kb. olyanok, hogy ráütök a billentyűzetre, aztán ami kijön. A fontosakat fejben tartom, és ahogy nézem olyan 15 és 35 karakter között szoktak lenni. Ezek ilyen egész vagy félmondatok, nem gyakori szólások vagy ilyesmik, úgyhogy megtippelni esélytelen őket. Van összesen fél tucat ilyen, úgyhogy nincs nehéz dolgom a megjegyzésükkel, begépelni pár másodperc alatt be tudom őket, úgyhogy nem vesztek sok időt vele, főleg amilyen lassúak a hivatalos, banki, stb. oldalak. Amit gyakran használok, az meg annyira beleégett már a kezembe, hogy a 20 karakter kevesebb mint 1 másodperc alatt megvan. Most mértem, hogy olyan 450 karakter per perccel gépelek, az több, mint 1000-nek felelne meg. Bár ahogy nézem még az sem egy világrekord sebesség. :D

Egyébként ha angol nyelvű oldalra regisztrálsz magyar szavakkal és angol szótárat használ a hacker, akkor máris elbukta a dictionary attack-jével. Ha meg vegyítesz több nyelvet is, akkor szintén, mert szerintem a legtöbbje nem is gondol ilyesmire. Még tovább lehet erősíteni rajta, ha hozzád kevésbé köthető, esetleg kitalált személynév, helységnév, irányítószám, ügyiratszám, telefonszám, ilyesmik is vannak benne. Ha ezeket kiejtés szerint és/vagy tájszólással, esetleg helytelenül írod, pl "A Macsupicsu lankás lejtőin" (27 karakter), akkor még erősebb lehet a jelszó. Ha a haverjaiddal gyerekkorodban kitalált szavak is belekerülnek, az meg kb. a feltörhetetlen kategória.

Viszont szerintem a fentinél gondolni kell arra is, hogy valaki egy ujjal gépel, maximum kettővel, és még úgy sem hibátlanul. Elég csak körülnézni a családban. Nekik kifejezetten kényelmetlen a hosszú jelszó...

Ami nekem kifejezetten tetszik jelszavakkal kapcsolatban az az RSA private key-nek adott passphrase. Mármint maga blokk titkosítás az gagyi rajta, de az elv szerintem tök jó, hogy jelszóval titkosítod a kulcsot, amit kódolásra használsz, és nem magából a jelszóból származtatod a kulcsot. Gondolom van néhány jelszó kezelő, ami ilyen elven generálja és tárolja le a jelszavakat és védi le mester jelszóval, de a legtöbbje gagyi, van/volt olyan is, ami plain text-ben tárolta le a jelszavakat.
25

Bank

Pepita · 2019. Jan. 14. (H), 11.06
Banknál nekem az (is) nagyon tetszik, hogy a username nem név, hanem egy kb 10 jegyű id, és még ezt is igyekszik a felületen megakadályozni, hogy "megjegyezze" a böngésző.
A jelszó egy token, amit vagy egy plusz hardvereszköztől kapsz (ezt asszem már nem nagyon használják), vagy egy mobilapp-ból, amiből szintén egy számlához csak egy lehet.
Természetesen nem lehet a tokent másolni (ezzel valamennyire egyetértek), de:
- mindössze 6 jegyű szám a token
- a webes felületen ennek ellenére jelszó mezőben van, nehogy meglásd, ha elgépelted :-D
- nem tudom pontosan meddig, de több, mint 30 másodpercig érvényes(!).
- Érdekes lehet egy céges számlánál az egyetlen token generátort használni.

Összességében szerintem ez nagyon gagyi megoldás, elsőször is én normálisan string-eket használnék ott username és password gyanánt, és mintegy kötelező második faktorként kérném a tokent.
A kifizetésekhez pedig elég csak a (z új) token.
Mondjuk más gondom is van ezzel a bankkal, lehet váltok majd, de az már offtopkic.
22

Limitációk

Hidvégi Gábor · 2019. Jan. 14. (H), 09.33
Szerencsére a legtöbben, akik ide írnak, fejlesztők, és van ráhatásuk a saját weboldalaik szabályaira.
24

Van...

Pepita · 2019. Jan. 14. (H), 10.55
Ezzel együtt gondolj arra is, hogy amiről Bence nem (sem) akar ítélkezni, azokat az oldalakat is (valamilyen) fejlesztők készítették, szóval igencsak van szórás a szakmában.
Tudnék mesélni nem is olyan régi story-t, amiben még plain/text jelszó is volt, de nem publikus.
Mondjuk a BKK remek T-systems-es jegyeladós rendszere gondolom ismertebb, és ott is elsőre a felhasználó volt a hibás, hogy hogyan merte megmutatni a szarvashibát...
Fel sem merült bennük, hogy ha hackerkedni akarna, akkor nem 1 db bérletet vesz 50 Ft-ért és nem jelzi a hibát...
29

Az en velemenyem (illetve

MadBence · 2019. Jan. 14. (H), 12.47
Az en velemenyem (illetve tanacsaim), ha valaki arra vetemedik, hogy jelszoval leptessen be:

  • Ne legyen maximalis hossz limit
  • Ne lehessen mondjuk a top 100 (vagy 1000) legnepszerubb jelszot valasztani (password, 123456, stb), ilyen listat az ember biztos tud szerezni
  • Ne legyenek idiota jelszo szabalyok (legyen benne szam, szimbolum, kis es nagybetu)
  • Ha vannak szabalyok, az legyen a minimalis entropiara vonatkozo (vagy valami modszer, ami jobban jelez a kitalalhato jelszavakra), mint a fentebb emlitett idiota szabalyok.


En tokre orulnek, ha a tom-bumps-guts-juju-cyclops-lyricism tipusu jelszavak mindenhol hasznalhatoak lennenek (ezt a jelszot az elobb generaltam).
31

Én még annyit hozzátennék,

inf · 2019. Jan. 14. (H), 17.31
Én még annyit hozzátennék, hogy legyen egy minimális hossz, pl 11 karakter már elvileg elég a mai világban. Az idióta szabályokkal kapcsolatban egyetértek, esetleg lehetne olyan megkötés, hogy csak latin1 és számok lehetnek, de ez sem feltétlen muszáj.