ugrás a tartalomhoz

Blowfish (crypt) függvény PHP-ban és a "salt string".

Dr Coon · 2012. Dec. 27. (Cs), 21.16
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!
 
1

Jelszo titkositas

janoszen · 2012. Dec. 27. (Cs), 23.47
A jelszo titkositasnak a kovetkezo ket szempontja van:

  • A jelszo ne legyen visszafejtheto az eltarolt adatbol, viszont az helyes jelszo legyen ellenorizheto.
  • A teljes titkositott jelszo adatbazis visszafejtese ne legyen kivitelezheto elore generalt titkositott jelszavak osszehasonlitasaval.


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.
2

sózás

Dr Coon · 2012. Dec. 28. (P), 09.15
Köszi, így már azt hiszem értem a dolgot. Akkor tehát a user adatbázisba összesen 3 adat, a felhasználónév, a jelszó hash-e plusz a só kerül. Bejelentkezéskor a felhasználónév alapján ki kell keresni az adott user-hez tartozó sót (ami mondjuk valamilyen random generált sztring) és azt használva előállítani egy hash-t a begépelt jelszóból, majd pedig ezt kell összehasonlítani az adatbázisban lévő hash-sel. Viszont így csak a jelszó titkosított maga a username pedig a sóhoz hasonlóan nem az, ami voltaképpen nem is nagy kockázat. Ez a szótárra visszafejtős téma gondolom csak akkor jelent potenciális veszélyt ha a jelszó egy értelmes szó. Javíts ki kérlek ha valamit rosszul értelmeztem.

Köszi!
3

Minél hosszabb és minél

Joó Ádám · 2012. Dec. 28. (P), 16.56
Minél hosszabb és minél kiszámíthatatlanabb a titkosított szó, annál nehezebb szótáras támadással feltörni. A szótár ebben az esetben nem feltétlen értelmes szavakat jelent (habár ezek egy támadás első lépcsője), hanem minden előre generált listát. A sózással a célod olyan szó előállítása, ami nem szerepelhet kész szótárban.
4

Ha a jelszót hash-elve

tgr · 2012. Dec. 30. (V), 22.11
Ha a jelszót hash-elve tárolod (azaz elvégzel rajta valami olyan transzformációt, amit a fordított irányban elvégezni gyakorlatilag lehetetlen), akkor az adatbázishoz hozzáférő támadó csak úgy tudja kitalálni a jelszót, ha az összes szóba jövő jelszónak kiszámolja a hash-ét, és megnézi, hogy melyikkel egyezik az általad tárolt hash.

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).
5

Thx!

Dr Coon · 2013. Jan. 2. (Sze), 19.27
Köszi, az említett két könyvtár hasznos tippnek ígérkezik, mindenképpen utánuk nézek.