Blowfish (crypt) függvény PHP-ban és a "salt string".
Sziasztok!
PHP alapú oldalon szeretnék felhasználókat kezelni és kielégítendő a legalapvetőbb biztonsági kívánalmakat a "user" adatbázisban csak a jelszók és a user id.-k hash-ét szeretném tárolni. Az általam eddig átnézett ajánlások alapján a PHP crypt függvénybe beépített Blowfish hash módszert szeretném használni. A kérdésem evvel kapcsolatban a következő: pontosan mi az a "salt string"? Addig okés, hogy ez valahogy belekerül a generált hash-be és bővíti azt, hogy nehezebben lehessen brute force módszerekkel megállapítani a forrást de mégis milyen string kell ide, hogy legyen is valami biztonságtechnikai jelentősége?
Köszi!
■ PHP alapú oldalon szeretnék felhasználókat kezelni és kielégítendő a legalapvetőbb biztonsági kívánalmakat a "user" adatbázisban csak a jelszók és a user id.-k hash-ét szeretném tárolni. Az általam eddig átnézett ajánlások alapján a PHP crypt függvénybe beépített Blowfish hash módszert szeretném használni. A kérdésem evvel kapcsolatban a következő: pontosan mi az a "salt string"? Addig okés, hogy ez valahogy belekerül a generált hash-be és bővíti azt, hogy nehezebben lehessen brute force módszerekkel megállapítani a forrást de mégis milyen string kell ide, hogy legyen is valami biztonságtechnikai jelentősége?
Köszi!
Jelszo titkositas
Az utobbi pontot vedi ki a sozas, azaz a salting. Minden felhasznalonak generalsz egy veletlen sot (ami nem titkos adat), amit hozzafuzol a jelszohoz titkositas elott. Magyaran szolva:
titkositottJelszo = titkositas(jelszo + so)Ha ez nem igy lenne, akkor egyszer legeneralsz egy hatalmas szotarra titkositott jelszavakat, majd a teljes adatbazist pillanatok alatt visszafejtheted.
Szemely szerint en a so mellett meg a titkositas modjat is el szoktam tarolni, igy konnyen "migralhato" ha az adott titkositasrol kiderul, hogy van benne sebezhetoseg. Amikor a felhasznalo bejelentkezik, frissitem a titkositott jelszot.
sózás
Köszi!
Minél hosszabb és minél
Ha a jelszót hash-elve
A sónak (amit az egyszerűség kedvéért képzelhetsz úgy, mintha a jelszóhoz hozzá lenne fűzve valami "egyedivé tevő" szöveg, amit aztán a jelszón kívül is letárolsz) két funkciója van:
1. ne lehessen előre kiszámolni a hash-eket. Ha nem lenne só, a támadó eltölthetne mondjuk egy évet az összes max. 10 betűs jelszó hash-ét tartalmazó táblázat legenerálásával, aztán amikor megszerzi az adatbázisodat, csak ki kéne keresnie a hash-eket ebben a táblázatban, vagyis lényegében azonnal megszerezné a jelszavakat.
2. ne lehessen egyszerre több jelszót megkeresni. Ha nem lenne só, vagy minden felhasználónak ugyanaz lenne, a támadó a fent említett táblázat legenerálása után ki tudná keresni az összes jelszót. Ha felhasználónként eltérő só van, akkor minden egyes felhasználóhoz le kell generálni a táblázatot, ami sokkal lassabb.
Ideális esetben a só globálisan egyedi és kriptográfiai értelemben véletleneszerű (= biztonságos véletlenszám-generátorral lett előállítva). A gyakorlatban ezeknek nincs nagy jelentősége, ugyanakkor nem is túl nehéz elérni - ha komoly jelszókezelő könyvtárat használsz, a sóval nem neked kell bajlódnod, azt a könyvtár kezeli a számodra láthatatlan módon. A cryptnek vannak különféle sebezhetőségei, ha nem te kontrollálod a környezetet (PHP verzió, operációs rendszer), ezért is érdemes könyvtárat használni. Ilyen például a phpass vagy a password_compat (utóbbi még béta, szóval komoly üzleti értékkel bíró oldalon nem használnám, de amúgy ez a legszebb megoldás).
Thx!