Új hozzászólás Aktív témák

  • fordfairlane

    veterán

    válasz Sk8erPeter #3416 üzenetére

    Most akkor kissé már össze vagyok zavarodva, akkor lényegében azt is mondhatnánk, hogy tök feleslegesek a titkosítások, mert úgyis mindent meg lehet kerülni.

    A hash algoritmus egy titkosítási módszer. A lényege, hogy az eredeti adatfolyamot helyettesítjük egy lenyomattal, ezt hívják hash kódnak. Miért jó az, ha a hash kód van meg az eredeti adatfolyam helyett? Mert a hash kód ismerete, kiszivárgása sem jelent problémát, elvileg a kódból nem lehet egyszerű eszközökkel "kinyerni", visszafejteni az eredeti adatokat. A hash kódokat több helyütt is használják. Ami nem mindegy, hogy mire használjuk, mit akarunk vele meggátolni.

    Gyakorlatilag miért nincs ebben a konkrét esetben jelentősége? Mert a hash kód a leírt rendszerből nem szivároghat ki. Abban az esetben juthat hozzá a hash kódhoz a támadó, ha az adatbázis tartalmát ki tudja elolvasni. Mikor tudja a támadó kiolvasni az adatbázis tartalmát, akár hash kód van benne, akár a plain text jelszavak? Hát elvileg csakis akkor, ha már van közvetlen hozzáférése hozzá. Ha pedig már közvetlenül hozzáfér az adatbázishoz, a jelszavakhoz, akkor valószínűleg egy egyszerűbb site-nál hozzáfér minden adathoz közvetlenül, akár írási joggal. Ebben az esetben a jelszavaknak meg már nincs jelentősége.

    Persze egy olyan rendszernél, ahol a jelszavakat ismerve további járulékos károkat lehet okozni (ugyanazzal a név:jelszó párossal más helyre is be lehet lépni pl.), akkor érdemes inkább hash kódot tárolni, úgy egyébként is ez a korrekt megoldás, de nem érdemes csak emiatt elbonyolítani egy egyszerűbb rendszert.

  • ArchElf

    addikt

    Amúgy a jelszavakat általában nem megérkezéskor, hanem már küldéskor hashelik, hogy a MITM támadások ellen is védjen.

    Pl., HTTP szabványos Digest authentikáció:
    http://en.wikipedia.org/wiki/Digest_access_authentication

    AE

  • ArchElf

    addikt

    válasz Sk8erPeter #3416 üzenetére

    Elsősorban a jelszavakat a jogosultsággal rendelkező felhasználóktól védik hasheléssel. Avagy a felhasználók érdekeinek védelme a rendszergazda kíváncsisága ellen.

    Tegyük fel, hogy te vagy egy cég tulajdonosa, és alkalmazol egy rendszergazdát. Nem biztos, hogy szeretnéd, ha szabadidejében az ügyfeleid nevében vásárolgatna...

    Ezután képzeld el mindezt egy bankkal. Így már érthető, ugye?

    AE

  • cucka

    addikt

    válasz Sk8erPeter #3416 üzenetére

    Milyen gyorsabb módszerekre kell gondolni? Nem azért kérdezem, mert kódfeltörés lesz a hobbim, hanem érdekel, hogy mi ellen, hogyan szokás védekezni.

    Kezdjük a kályhánál.
    A hash algoritmusok lényege, hogy van nagyon sok fajta különféle bemeneti adatod és ezekhez kell hozzárendelni egy szűkebb halmazból egy elemet. Jelen esetben a nagyon sok fajta különféle bemeneti adat a lehetséges jelszavak halmaza (pl. n..m hosszúságú alfanumerikus stringek), a szükebb halmaz pedig a 128 bites számok halmaza (ezek a lehetséges md5 hash-ek). A hash algoritmus azt csinálja, hogy a bemeneti adatból egy hasht gyárt. Nyilván, az algoritmus több eltérő bemeneti adathoz is kiadhatja ugyanazt a hash kulcsot, ezt hívják ütközésnek. Akkor jó egy hash algoritmus, ha a hash kulcs alapján nem tudsz olyan bemeneti adatot mondani, aminél ütközés lép fel.

    A hash kulcs feltörésének legegyszerűbb módja a próbálgatás, aminek a műveletigénye O(2^n), azaz exponenciális. Ezt gyakorlatilag senki sem használja. Vannak más módszerek is, mint a "rainbow tables", ezekkel lényegesen gyorsabban lehet ütközést taláni, de ez a gyorsaság még mindig több órát vagy napot jelent. Ezen kívül ha jól emlékszem, az md5-höz sikerült találni polinomiális időben lefutó algoritmust, viszont ott a konstans szorzók brutálisan nagyok, tehát szintén lassú (meg kell keressem a forrást, jópár éve olvastam erről, tehát lehet, hogy rosszul emlékszem). Leginkább ezért ajánlják a nagyokosok, hogy md5 helyett sha1-el kódold a jelszavakat.

    Az ütközések keresése elsősorban hitelesítésnél fontos (pl. hitelesített szoftver), ezeknél megérheti a befektetett időt az ütközések keresése. Ha valaki talál egy adatbázist több száz vagy ezer lekódolt jelszóval, akkor ott nem éri meg ezzel tökölni.
    Az ütközés kikerülésének a legegyszerűbb módja a salt, aminek lényege, hogy kódolás előtt a kódolandó adathoz hozzá kell fűzni, így gyakorlatilag hiába talál bárki ütközést a hash értékhez, az eredményül kapott jelszó nem fog működni.

    Összefoglalva: a jelszavak visszakódolása egyrészt nagyon sok idő, másrészt a salt miatt egyáltalán nem biztos, hogy eredményes, tehát ha valaki hozzá is fér az adatbázisodhoz, jó eséllyel nem fogja ezt csinálni. Ezért fölösleges annyit pörögni a témán. Természetesen a hash algoritmusok nagyon fontosak, csak pont ebben a speciális esetben jelenthető ki, hogy nem túl érdekesek.

    A jelszavakhoz való illetéktelen hozzáférést elsősorban phishing oldalakkal szokták csinálni, de mondjuk a session lopás is lehet eredményes.

  • Sk8erPeter

    nagyúr

    válasz cucka #3413 üzenetére

    Milyen gyorsabb módszerekre kell gondolni? Nem azért kérdezem, mert kódfeltörés lesz a hobbim, hanem érdekel, hogy mi ellen, hogyan szokás védekezni.

    (#3414) fordfairlane: "Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat :D"
    Ez azért meglepett :D Most akkor kissé már össze vagyok zavarodva, akkor lényegében azt is mondhatnánk, hogy tök feleslegesek a titkosítások, mert úgyis mindent meg lehet kerülni. :D És ez egyben azt is jelenti, hogy felesleges játszadozni az md5-titkosítgatásokkal meg hasonlókkal... Na de valami célja mégis van, nem? :D Nem épp az, hogy legalább megnehezítsük a dolgát a támadóknak? Mindketten azt mondjátok, hogy inkább elméleti, mint gyakorlati "haszna" van a dolognak. :F

  • cucka

    addikt

    válasz fordfairlane #3414 üzenetére

    Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat
    Én az md5-nél tartok, gondolom kell még nekem is pár év, hogy továbbfejlődjek erre a szintre :D

    Amúgy én is ki tudok találni számtalan hülyébbnél hülyébb algoritmust a kódolásra. Például fogjuk a szó hosszát, abból gyártsuk salt-ot úgy, hogy kiírjuk római számmal a hosszt, utána kódoljuk le md5-el, vegyük az első n karaktert és az legyen az sha1-es kódolás salt-ja. Ezt most találtam ki, hasonlóan biztonságos, mint amit az említett cikkben írtak, csak ugye totál fölösleges.

    Más kérdés, mindenkihez. Zend Certification-el kapcsolatban van valakinek tapasztalata? Röviden: a Zend biztosít lehetőséget egy ilyen vizsgára, ami ha sikerül, kapsz egy plecsnit. Ér ez valamit? Egyáltalán ismeri bárki is ezt? (Elsősorban az állásinterjúkon képviselt súlya érdekel a dolognak)

  • fordfairlane

    veterán

    válasz cucka #3413 üzenetére

    Igazából ez egy elméleti téma, gyakorlatilag meglehetősen haszontalan, tehát ha nem muszáj, akkor nem kell foglalkozni vele, az egyszerű md5 vagy sha1 bőven megfelelő erre a célra.

    Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat :D , mert a felhasználók elfelejtik, és ha a támadó megszerzi az adatbázist, akkor annak a rendszernek már egyébként is régen lőttek, úgyhogy az a legkisebb gond.

  • cucka

    addikt

    válasz Sk8erPeter #3411 üzenetére

    A tárgyi tévedések mellett a cikkel a fő probléma a feltételezés, hogy ha egy támadó hozzáfér az adatbázisodhoz, akkor azt fogja csinálni, hogy visszakódolja az ott tárolt jelszavakat.
    A valóság, hogy a jelszavakat nem md5 (vagy más) hash-ek visszafejtésével szerzik meg a rosszindulatú emberek, vannak erre gyorsabb módszerek is. A másik, hogy ha már hozzáfértek az adatbázisodhoz, akkor az a legkisebb problémád, hogy meglátják a kódolt jelszavakat.

    Igazából ez egy elméleti téma, gyakorlatilag meglehetősen haszontalan, tehát ha nem muszáj, akkor nem kell foglalkozni vele, az egyszerű md5 vagy sha1 bőven megfelelő erre a célra.

Új hozzászólás Aktív témák

Hirdetés