Poul-Henning Kamp: az md5crypt már nem tekinthető biztonságosnak

Titkosítás, biztonság, privát szféra

A LinkedIn incidens apropóján írt egy cikket az ACMQUEUE hasábjaira Poul-Henning Kamp FreeBSD fejlesztő, az md5crypt megalkotója. Kamp írásában azt elemzi, hogy miért hibázott a Linkedin, mikor a jelszavakat unsalted SHA1 hash-ek formájában tárolta.

A '90-es évek közepén Kamp, hogy a standard UNIX crypt(3) gyengeségére - könnyen, gyorsan "brute force"-olható - megoldást adjon, megalkotta a md5crypt-et. Az md5crypt feltehetően a legszélesebb körben használt jelszókódoló. Éppen ezért kell felhívni a figyelmet arra, hogy napjaink hardverei mellett az md5crypt már nem tekinthető biztonságos megoldásnak. Körülbelül annyit ér ma, mint 1995-ben a DES-alapú standard UNIX crypt(3), ami miatt megszületett. Hogy ez mennyire így van, azt maga a szerző mondja el "Md5crypt Password scrambler is no longer considered safe by author" írásában.

Poul-Henning Kamp, az md5crypt szerzője mindenkinek azt javasolja, hogy késedelem nélkül váltson erősebb jelszókódolóra.

( trey | 2012. 06. 09., szo – 13:25 )

Lazán kapcsolódik:

A FreeBSD-s Dag-Erling Smørgrav felvetette, hogy mi lenne, ha a FreeBSD a legtöbb Linux disztróhoz hasonlóan nem az MD5-öt, hanem az SHA-512-t használná alapértelmezetten, ha már évek óta úgyis támogatja az SHA-256-ot és SHA-512-t.

Valaki azt kérdezte, hogy ha az SHA2 évek óta támogatott, akkor miért nem szerepel a releváns man oldal(ak)on.

Azóta a hiányzó infó pótlása megtörtént.

--
trey @ gépház

( eax | 2012. 06. 09., szo – 13:26 )

Ami hulyeseg benne, az ez: "All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm".

--
"You're NOT paranoid, we really are out to get you!"

- vagy ő is olyan, mint némelyik túltervezős, hogy hát "minden 10 főnél nagyobb cégnél kötelezővé kéne tenni egy rendszergazda jelenlétét és a saját vpn-t, telefonközpontot, és ... (mégha PC-ket se használnak, akkor is)"

- vagy arra gondol, hogy nem ártana egy salt-olásnál egy lépéssel komolyabb csavart is berakni a történetbe, erre láttam már nem túl bonyolult példákat

Tíz fő alatt: Magyarországon 8,7 körül van az átlagos alkalmazotti létszám.

Cégprofiltól függően, jól felfogott érdeke hogy legyen rendszergazdája, meg jogásza, meg könyvelője.

0. Ha külső könyvelőhöz viszed a cuccod, ott mindig van gyakornok, vagy kezdő, aki 10-ed annyiért gürizik, mint a főnöke. Na ő fogja kikeresni a számlákat neked.
1. Megvan, hogy hova viszed javíttatni a gépet. Megkened a szervízest, felrak vnc,keyloggert, észre nem veszik.
2. Adsz egy kis pénz a telefonosoknak és olyan adót raknak a központba hogy csak fütyül.

-És már alád is igértek a következő árajánlatban.
-Pár ilyen és megvesz kilóra a konkurencia, te meg eladod a termelőeszközt, hogy kifzesd a munkabért.
-Fenyomnak az NAV-nál, akik keres alapon.

Csak ironikusnak találtam a tíz fős cégekről szóló szösszenetedet.

Részben egyetértünk. Arra próbáltam rávilágítani, hogy nem kéne mindenkinek spanyolviaszt nyomnia, sokadik házi fejlesztésű programot látom bedőlni kiscégeknél, sokadik piaci modellt látom visszafelé elsülni. Mindezt úgy, hogy közben tanulják, utálják, nem is akarják, mert nyűg, de azért belekezdenek, mert az menő.

Mindennek lesz előnye és hátránya, ha csak innen madártávlatból nézzük, ejtsd felvehetsz egy embert, aki a te rendszergazdád, de mivel nem nagycéges háttérben van, kiesik bizonyos körforgásokból, tapasztalata is egyoldalúvá vállhat, ... Ezzel szemben a nagycégekre való kiszervezés elembertelenít, kapcsolatok nem lesznek olyan szorosak, 1 leszel az 1000-10000 ügyfélből, értem én.

Szerintem mindenki foglalkozzon azzal, amivel tud, kicsit kevesebb "mindenesre" lenne szükség, aki amúgy csempézik hétvégente otthon, a gyereknek ő a matektanára, amúgy programozónak tanult, de most már ő a cégvezető, és a PR-os is egyben. Helyette lehetett volna jobb programozó, kereshetett volna egy jobb cégvezetőt, tanárt a gyereknek, ..., és mindeközben nem utálta volna meg a munkáját.

Szerinted megéri egy "átlagos" 10 fős cégnek saját rendszergazdát alkalmazni, saját CMS-t / webshop-ot és raktárkezelőt fejlesztetni, felvenni egy grafikust a reklámanyagok elkészítésére, valakit facebook-ozásra, ... ?

(adatot kösz, bár megnézném mennyire átlag, tehát a cégek hány százalékánál van 8-12 fő között az alkalmazotti szám, az átlag nekem még nem elég)

A kíváncsiságkielégítő osztag jelenti:

19451 8-12 fő közötti áfa kötelezett cég van.
428913 cégnél van alkalmazott, 3346845 fővel, 1500281 cégből.
Tehát a válasz 4,5% a cégeknek 8-12 főt foglalkoztat.
/nem valami normál eloszlás/

2483 minősített adózó van, ezeknek nincs kint a fogl. létszám.
76276 EVA alany van, nekik sincs kint.

2012.02.24-i adatbázis, 85Mb xlsx, azóta nem volt kedvem töltögetni. Ja, közérdekű adat, mielőtt bármi gyanúsra gondolna.

(nekem a 1.5 millió cég a kevés, mert 2 milliót ír ki a NAV, de letöltve ennyi sor volt.)

Más: munkaerőpiaci adatok: http://statinfo.ksh.hu/Statinfo/themeSelector.jsp?page=2&szst=QLI

A válaszok:
Cégprofiltól függ, ha csavart gyárt, vendéglát, vagy vadásztat, vagy permetez nyilván nem kell rendszergazda, saját CMS/webshop.
Ha szállít, épít, tervez, sok ügyfele van akkor kell IT.
Ha kisker akkor feldobja vaterára, bolt a marsonra, nem kell webshop.
Ha nagyker csináljon saját webshopot, privát boltot a kiskereknek.
Aztán vannak az őrültek, akik egyedit akarnak:
1. mert megszívták pénzlehúzó webdesigner cégeknél.
2. sok egyedi funkció, amit nem lehet wp,joomla,stb-ben kihozni.
3. prestige

"Jah, bár nem egyedi hash algoritmusra gondol, hanem egyedi felhasználására a szabványos hash algoritmusoknak."

Tudom, de a fejlesztok az egyedi felhasznalast is 10-bol 10-szer elrontjak. A legjobb pelda erre az a "tapasztalt PHP programozo", aki itt keresett allast egy olyan peldakoddal, ahol kb. nullara sikerult butitania az md5+sha1 kombot.

--
"You're NOT paranoid, we really are out to get you!"

Kerestem, de sajnos nincs meg. Nagy vonalakban azt csinalta az illeto, hogy md5-el hashelte a jelszot, konvertalta hex stringre, majd ennek levagta az elejet (!), a helyere tette a hex stringre konvertalt fix salt-ot, majd az egeszet hashelte sha1-el.
Igy ha rovid a salt, az a jobbik eset: akkor nem ved rainbow tabla ellen. Ha hosszu, akkor viszont csak egy par byte marad, ami igazabol a jelszotol fugg. Szelsoseges esetben meg akarmilyen jelszoval beenged. :)

--
"You're NOT paranoid, we really are out to get you!"

Ez pont az a hozzáállás, ahogy a nagyordó működik: a konstanst, meg a lineáris tényezőket elhanyagolhatjuk. Nem, nem hanyagolhatjuk. Nem kerül szinte semmibe, és mégis +1 védelmi réteg, ha azt akarja törni, MUSZÁJ belső infóval rendelkeznie az illetőnek. Az sosem árt, ha van még egy védelem. Persze, ne feltételezd, hogy nem ismerik, de ne is terjeszd.
----
Hülye pelikán

Lehet ezt csűrni-csavarni, de a lényegen nem változtat: mi most egy olyan szcenárióról beszélgetünk, amikor egy támadó MÁR RENDELKEZIK belső infóval és megszerezte a jelszó hasheket tartalmazó adatbázist... Egy profinak innen már nem jelent akadályt módosítani valamelyik jelszótörő programot, hogy az illeszkedjen a módosított sózási algoritmushoz, egy kiddienek meg eleve odáig se szabadott volna eljutnia, hogy hozzáférjen a jelszavakhoz.

Miért beszélünk olyanról, ahol rendelkezik belső infóval? Ha kapok egy adatbázis dumpot, hogy ne, jelszavak, akkor nem rendelkezem belső infóval. Akár értek hozzá, akár csak be tudok lőni egy hidrát, info nélkül gondot fog okozni egy custom algoritmus.
Nem felesleges csűrni-csavarni, mert a túlzott általánosítás csak messziről néz ki jól. A világ nem fekete és fehér, hogy valaki vagy mindent tud, vagy semmit. Védekezni sosem felesleges, főleg, ha olcsó.
----
Hülye pelikán

Nem értem miről beszélsz. Az nem lehet biztonsági alapja semminek, hogy ha te kapsz egy adatbázis dumpot, akkor mit tudsz vele kezdeni. A kérdés az, hogy aki eredetileg hozzáfért az adatbázishoz és a dumpot készítette, annak mennyire lett volna nehéz a további információkat is beszerezni hozzá.

Ez meg tipikusan egy olyan dolog, amiről elméleteskedni ugyan lehet, de a gyakorlat azt mutatja, hogy ahol így hozzá lehet férni a jelszó hashekhez, ott máshoz is sikerül hozzáférést szerezni rövid úton, ha a támadó akarja. Ergo az SQL injection játékos script suttyó vs. Blackhat különbség továbbra is fennáll és a jelszavak megtörése nem az egyedi algoritmuson fog múlni.

Azt meg már láttuk rövid úton illusztrálva, hogy mennyire jók az ilyen kriptográfiai "custom algoritmusok"...

"A kérdés az, hogy aki eredetileg hozzáfért az adatbázishoz és a dumpot készítette, annak mennyire lett volna nehéz a további információkat is beszerezni hozzá."

Igy van. Ha mast nem, gondolj arra, hogy dumpolas elott nyugodtan betolhat a db-be tetszoleges mennyisegu altala valasztott pw-t. Ebbol talan meg egy tokismeretlen algo is rekonstrualhato, a meglevok valamilyen kombinacioja viszont biztosan.

--
"You're NOT paranoid, we really are out to get you!"

Az, hogy te nem mozogsz otthonosan ebben a temaban, es nem tudsz mit kezdeni egy db dumppal, az csak rolad mondja el azt, hogy nem hordasz fekete kalapot. Es kesz, ez ennel tobbet nem jelent, az igazi hackerek valoszinuleg tovabb fognak szimatolni, amig meg nem tudjak a szukseges infot.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Ez pont az a hozzáállás, ahogy a nagyordó működik"

Nem, ez egyaltalan nem az. Ez az a hozzaallas, amit a szakmaban kockazatelemzesnek hivnak. Egyik oldalrol csokkented a kockazatot (azzal a max. nehany oraval, ami ahhoz kell, hogy a tamado hozzaigazitsa a hash cracker cumojat az algodhoz), a masik oldalrol pedig noveled azzal, hogy hibazhatsz (es jo esellyel fogsz is) az algoritmus tervezese/implementalasa soran.

--
"You're NOT paranoid, we really are out to get you!"

TFH kov algoritmusom van (itt helybe felirva, nem production kod sehol):


from hashlib import sha256
from random import random
config = {globalsalt: 'm3sz1kr3t'}
def user_set_pass(username, password):
__salt = sha256(str(random())).digest() # cel: 256 bit random adat, fix hossz
__stored_pwd = salt + sha256(config['globalsalt'] + salt + password).digest()
__store(username, {'pass': stored_pwd})

def authenticate(username, password):
__user = retrieve(username)
__if user:
____stored_pwd = user['pass']
____salt = stored_pwd[0:32]
____hashdigest = stored_pwd[32:]
____return sha256(config['globalsalt'] + salt + password).digest() == hashdigest
__else:
____return False

Akkor en a state of the art szerint nem vagyok eleg biztonsagos, ezert le kell vennem a Vajda-konyvet, es uj cuccok utan nezni? Aki ezt megfejti, az mar annyira raer, hogy tuti hogy valami kormanynak dolgozik, nem? En tudom rosszul?

(szerk: esetleg meg egy username-et be lehetne venni a hashbe, de akkor megszunne az az amugy sysadmin szinten kenyelmes funkcionalitas, hogy copy-paste-zni tudom a hash-t db-ben ha be akarom allitani a jelszot... teny, additional vedelem is... azzal mar eleg?)

Valóban, kicsit javítanom kell:

store = 256(rand) + 256(globalsalt + salt + password)

Ez 64 byte lesz (2 x 32) ami 512 bit.

read = előzőleg letároltból 32 byte-os alsó feléből veszi a sót a felső 32 byte-hoz.

Magyarul minden külön jelszóhoz külön sót generál és tárol.

Rendben, de ha hozzáférnek belülről a géphez, akkor ott van az algoritmus is, látják hogy lett generálva. Tehát szerintem az erőssége annyit ér, amennyire az algoritmus birtokában is erős.

Azt gondolnám, hogy ez így nem erősebb, mintha azonos sót használsz mindegyik letárolt hash-hez.

"A sót nem állíthatod elő különböző véletlen adatként minden egyes jelszó tároláskor, hanem egyformának kell lennie "

Nem.
Azt erdemes tudni az osszes Merkle-Damgard hashrol, hogy ezek egyaltalan nem "atomikus" muveletek, hanem kicsit olyanok, mint a CRC: vegigmennek a hashelendo inputon blokkonkent, update-elik a belso allapotukat, es a vegen abbol lesz valami output. Ebbol kovetkezik, hogy a legtobb hasht "tovabb lehet szamolni", a legegyszerubben blokkhatartol (ezt ugy hivjak, hogy length extension attack).

Tehat ha van egy nagy konstans salt-ed a jelszavak elejen, akkor egy tamadonak nem kell ennek megfelelo meretu rainbow tablat generalnia, hanem csak a hash algoritmus IV-it kell modositania abba az allapotba, ahova a salt vegigszamolasa utan kerulne.

--
"You're NOT paranoid, we really are out to get you!"

Jók amikor látszanak a mélységek :)

Had közelítsem meg egy kicsit egyszerűbben: Te most azt mondod, hogy a hash előállítási algoritmusa nem is olyan jó? (Pedig a sarki közértbe nekem azt mondták hogy de :))

Vagy itt most azért nem olyan egyértelmű visszaélési lehetőségről beszélsz a hash algoritmus tekintetében? Pl. nem minden esetben használható ez a támadás fajta - amit írtál?

Mennyire racionális vajon a veszély olyan db-ben lévő jelszavak visszafejtésére, amelyek egy konstans salt + pass módon lettek generálva (semmi egyéb extra) ? (Profik által írt célszoftverekkel felvértezett Pistikékre gondolok - államhatalmi szervek ellen nem célom okosabbnak lenni) ?

"Te most azt mondod, hogy a hash előállítási algoritmusa nem is olyan jó?"

Nem, ez egyszeruen egy tulajdonsaga, amire figyelni kell, ha hasznalni akarod. Igazan talan nem is jelszotarolasnal, hanem pl. HMAC-nal.

"Vagy itt most azért nem olyan egyértelmű visszaélési lehetőségről beszélsz a hash algoritmus tekintetében? Pl. nem minden esetben használható ez a támadás fajta - amit írtál?"

Nem, ez kifejezetten akkor mukodik, ha a tamado rainbow tablat akar generalni, ha nem akar (es altalaban ha soha tobbe nem tudja felhasznalni, akkor nem akar), akkor nyilvan nem. Egyebkent a fix salt-al realisabb gond, hogy igy az osszes jelszot egy menetben lehet torni, szemben a random salt-al, ahol mindegyiket egyenkent kell.

"Mennyire racionális vajon a veszély olyan db-ben lévő jelszavak visszafejtésére, amelyek egy konstans salt + pass módon lettek generálva (semmi egyéb extra) ?"

Kicsit kisebb, mintha csak sima hash-eket hasznalnal.

--
"You're NOT paranoid, we really are out to get you!"


from hashlib import sha256
from random import random
config = {globalsalt: 'm3sz1kr3t'}
def user_set_pass(username, password):
  salt = sha256(str(random())).digest() # cel: 256 bit random adat, fix hossz
  stored_pwd = salt + sha256(config['globalsalt'] + salt + password).digest()
  store(username, {'pass': stored_pwd})

def authenticate(username, password):
  user = retrieve(username)
  if user:
    stored_pwd = user['pass']
    salt = stored_pwd[0:32]
    hashdigest = stored_pwd[32:]
    return sha256(config['globalsalt'] + salt + password).digest() == hashdigest
  else:
    return False

1. a random() entrópiája nem 256 bites, így a belőle számolt sha256 hash sem lesz annyi... tehát már az első célodat sem érted el ("256 bit random adat")
2. az str(random()) nagyon fájdalmas, egy kriptos valószínűleg sírna is miatta
3. a salt által felvehető értékeket így egy támadó előre kiszámolhatja és egy 1 terás rainbow táblában eltárolhatja ("precomputed intermediate")
4. nincs benne key-stretching
5. szinte csak annyit értél el vele, mintha egy hosszabb jelszót kellene megtörni sha256 hashből (feltéve, hogy a globalsalt nem megszerezhető, mert akkor még annyit se ;)

A $RANDOM az 0-32767 értékeket generál (azaz 2^15 a variációk száma), ha háromszor használod azzal még mindig csak 45 bitre növelted az entrópiáját, ami kriptográfiai dolgokhoz tipikusan még mindig kevés, de az általad használt temp file race condition támadások elleni védelemhez már elég.

Nyilván a salthoz használt random entrópiája növelhető hasonló módszerrel, ha valódi RNG a forrás, de a megfelelő sózáshoz még sok minden kell (lásd key-stretching).

1. A random az most talalomra volt oda, kellett egy olyan entropiaforras, amire nem kerdeznek hogy mit csinal...
2. lasd fent :)

4. key-stretching szandekosan nincs benne, nem az a cel ugyanis, hogy ezzel lassitsuk a brute force attack munkajat, hanem hogy eleg zagyva dolgot talaljunk ki ahhoz, ami rainbow tablaval mar nem megy
5. nyilvan kulonbozo szintek vannak, adatbazis szivargas, forraskod szivargas, ill. rendszerszivargas.

Ez igazibol a unix-os shadow megoldasnak akart lenni egy modernebb valtozata, hosszabb salt-tal.

Sz'al azt mondod, hogy hiaba nem konstans a salt, nem eleg besaltolni a jelszavakat, mert epit egy custom rainbow tablat az osszes saltra? De legalabb mar statikus - "internetrol letoltom" - rainbow tabla tamadasok ellen szepen ved,nem? Vagy arra se jo?

"$id$salt$encrypted", where "$id" is the hashing algorithm used (On GNU/Linux, "$1$" stands for MD5, "$2$" is Blowfish, "$5$" is SHA-256 and "$6$" is SHA-512, crypt(3) manpage, other Unix may have different values, like NetBSD).

(Forras: Wikipedia)

De nekem ne azt mondd, hogy ez mennyire fatalis hibakkal van tele, egy olyan algoritmus, amit az ejszaka kellos kozepen irtam, illusztracios celbol, es kb. minden placeholder benne.

Ezt azert irtam hogy szetszedjuk - nem tarolok sehol semmilyen jelszot szerintem a mostani rendszereimen, masok foglalkoztak ezzel / loginless ficsor.

Nekem egy olyan algoritmust mondj, ami idefer egy kommentbe, nem valami 3 ember altal hasznalt lib tagja, es nem torik fel ket nap alatt egy orosz mechanikus torokon.

Koszi.

nem, egy szoval nem allitottam, hogy szakerto vagyok, ellenben az altalad feltett kerdesre valaszoltam; ideznem:

"Nekem egy olyan algoritmust mondj, ami idefer egy kommentbe, nem valami 3 ember altal hasznalt lib tagja, es nem torik fel ket nap alatt egy orosz mechanikus torokon."

___
info | Tresorium

oke, akkor azt mondod, huzza le mindenki a PBKDF 2-es lib-et (amit csak pythonra latok itt), es hasznalja?

Ket sor valtozik amugy:


import PBKDFv2
...
  stored_pwd = salt +PBKDFv2().makeKey(password, salt+config['globalsalt'],1200,64)
....
    return PBKDFv2().makeKey(password, salt+config['globalsalt'] == hashdigest

A salt() hisztire akkor meg gondolom az str(random) helyett kell egy

import random
random_source = random.SystemRandom()
...

  salt = ''.join(random_source.choice('abcdef0123456789') for _ in xrange(32)) #hogy digest-szeru legyen

Ami ugyan urandom-os, de ha kell, akkor lehet hasznalni ugyanazzal az api-val a truly_random modult mondjuk vagy kezzel kiolvasgatni /dev/random -bol.


import trulyrandom
random_source = trulyrandom

Na es akkor lassuk egybe, ez igy megfelel-e?


import PBKDFv2 #innen: http://pages.cs.wisc.edu/~lenz/luks/PBKDFv2.txt - pycypher kell neki, a XOR modult hasznalja belole
import truly_random #innen: https://hkn.eecs.berkeley.edu/~dyoo/python/truly_random/ - a regi valtozatot erdemes nezni kodkent

random_source = truly_random
config = {globalsalt: 'm3sz1kr3t'}

def user_set_pass(username, password):
  salt = ''.join(random_source.choice('abcdef0123456789') for _ in xrange(32)) #hogy digest-szeru legyen
  stored_pwd = salt +PBKDFv2().makeKey(password, salt+config['globalsalt'],1200,64)
  store(username, {'pass': stored_pwd})

def authenticate(username, password):
  user = retrieve(username)
  if user:
    stored_pwd = user['pass']
    salt = stored_pwd[0:32]
    hashdigest = stored_pwd[32:]
    return PBKDFv2().makeKey(password, salt+config['globalsalt'] == hashdigest
  else:
    return False

Akkor ez igy megfelel?

A fentebbi ket algoritmus vegulis konnyen portolhato, az egyik egy webservice hivas vagy fajlolvasas, a masik matek. A XOR cipher remelhetoleg ugyanazt csinalja (nincs modomban ellenorizni, mint ezek.

Akkor az a verdikt, hogy ha valaki a fentebbi algoritmusokat leimplementalja, van neki egy BME-Crysis altal "certifikalt" szintu jelszohash-megoldasa, ami a szivarvany-tablak ellen a kovetkezo mondjuk 2 evben meg vedelmet nyujthat?

bocs, az nem pycypher hanem pycrypto.

Az elso modul ugy jott, hogy beirtam gugelbe az altalad nyomatott keywordot es ez volt az elso talalat,meg a kovetkezo 5 is.

A masodik modul ugy jott, hogy olyat kerestem, ami legalabb a /dev/random entropiaszintjet hasznalja, ez a truly_random, ket valtozata van, az egyik siman megnyitja a /dev/random-ot, es kiszedi amit ott lat, a masik valami cezium atombomlas alapjan csinal randomot, mondjuk szvsz azt a webservice hivast egy ugyes betoro elkapja, es tudja az osszes randomunk salt-jat...

( hrgy84 | 2012. 06. 11., h – 01:53 )

Valahogy a cikk nem lett ertelmes.

"Kamp írásában azt elemzi, hogy miért hibázott a Linkedin, mikor a jelszavakat unsalted SHA1 hash-ek formájában tárolta."
"[...] az md5crypt már nem tekinthető biztonságos megoldásnak."

Ha az a vegkovetkeztetes (nem olvastam el a linkelt cikket), hogy az SHA1 is szeleskoruen alkalmazott, es ezert nem biztonsagos, azt irjuk mar bele a cikkbe, mert ez igy se nem szakmai, se nem ertelmes. Elso blikkre nincs koze az MD5Crypt-nek az SHA1-hez, a ketto ket kulonbozo algoritmus.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( uid_6846 | 2012. 06. 11., h – 21:35 )

Úúú! Na, most már mindegy, ha ezt hamarabb tudom, akkor nem regelek md5crypt felhasználónév- és jelszó-párossal.