PHP crypt által visszaadott érték
Nézegetem pár órája a doksit, de nem értem: miért adja vissza a crypt függvény a "salt" értékét a kimeneten? Ha nem nekem kellene megadni, akkor érteném, de így, hogy én töltöm ki...
És ehhez kapcsolódva: nem gáz, ha az adatbázisban, a kódolt infó (pl. jelszó) mellé lerakom a létrehozásakor használt "só"-t? (tehát pl. az SHA256-tal használt crypt kimenetét 1:1-ben beírom a jelszó mezőbe)
■ És ehhez kapcsolódva: nem gáz, ha az adatbázisban, a kódolt infó (pl. jelszó) mellé lerakom a létrehozásakor használt "só"-t? (tehát pl. az SHA256-tal használt crypt kimenetét 1:1-ben beírom a jelszó mezőbe)
Belekódolva
Na jó, de a só értékét én
Ráadásul azzal, hogy hozzáfűzi plain textben a hash-hez, plusz munkát ad, mert
- ha nem akarom berakni a hash részeként mondjuk a user táblám jelszó mezőjébe, akkor le kell választani az eredményről
- ha úgy rakom bele a jelszó mezőbe, hogy a sót is tartalmazza, akkor ha valaki hozzájut a mező tartalmához, megkönnyítettem a betöréssel kísérletező dolgát, mert a kezébe adom a sót.
Valamit rosszul értelmezek?
Így működik
Kriptográfiailag a só értéke nem számít titkos adatnak, hiszem csak a szivárványtáblás jelszó törés ellen véd meg. Ennek felhasználónként egyedinek kell lennie és ismertnek kell lennie a jelszó sikeres ellenőrzéséhez. Ha az egész rendszerben egy sót használsz, akkor akár ne is használj sót, mivel szivárvány táblát egy adott sóra generálni nem sok meló.
Ezekszerint a
Úgy gondoltam, ezek bármikor újragyárthatóak _viszonylag_ gyorsan.
Titkosítás terén gyakorlatilag 0 ismerettel rendelkezem, csak valahogy úgy képzeltem, ha egy titkosított adatot védeni akarok, akkor a kódolásról igyekszem minél kevesebb információt elárulni a kíváncsiskodóknak.
Nem úgy terveztem, hogy azonos "só"-t használok minden jelszóhoz, pusztán az előállításuk algoritmusa lenne azonos. Például a jelszó módosításának időpontja, esetleg a felhasználó nevének pár karaktere, ilyesmi.
Szóval olyan karakterek, amik egyébként ott vannak a kódolt mező mellett, de úgy, hogy a forráskód nélkül nem lehet egykönnyen kitalálni. Ezért értetlenkedtem.
Köszi.
a szivarvanytabla egy elore
ezzel nagysagrendileg gyorsitani lehet a brute-force/dictionary attack tipusu tamadasokat, mert nem minden jelszora kell az osszes kombinaciot kigeneralnod, hanem gyakorlatilag csak egy B-tree-ben keresel, jo esetben a memoriaban.
ehhez kepest ha megsozod a jelszot, akkor (ha megfeleloen eros/hosszu a jelszo,) akkor:
- ha nem ismered a so-t, akkor nagysagrendileg nagyobb rainbow tabla kell, hogy megtalald a plain alakokat, es mivel nem tudsz semmit a so-rol, ezert nem biztos, hogy rajosz, hogy a plain alak melyik resze volt az eredeti jelszo, mi volt a so(ha csak konkatenaltad a jelszot, meg a sot, akkor azert ki lehet talalni)
- ha mar ismered a sot (akar azert mert ott van a db dumpodban, akar mert az elozo modszerrel visszafejtettel parat), es azt is, hogy hogyan kell a sot a plain jelszohoz adni, akkor kigeneralhatsz egy kifejezetten ilyen algoritmushoz tartozo rainbow tablat, amiben mar megint gyorsan tudsz keresni.
- ha viszont minden jelszohoz eltero salt tartozik, akkor hiaba ismered a salt-ot, minden egyes jelszohoz ki kellene generalnod a rainbow tablat, ami gyakorlatilag azt jelenti, hogy nincs ertelme rainbow tablat hasznalni.
http://en.wikipedia.org/wiki/Salt_(cryptography)
Tyrael
Köszi
Tehát a sózás elsősorban nem egy-egy hash védelmére való, hanem arra, hogy a jelszó hash-eket tartalmazó adatbázisból nehezebb legyen kiválogatni a szivárványtáblákban megtalálható mintákat.
Hm. Kicsit másképp képzeltem.
vegso soron 1-1 jelszot is
de nagyjabol errol van szo, igen.
Tyrael