Ú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_authenticationAE
-
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
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
"
Ez azért meglepettMost 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.
É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?
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.
-
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 szintreAmú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
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
, 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
- iPad topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- BestBuy ruhás topik
- N€T0X|N: SSD cserék
- OLED TV topic
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Számtech boltosok memoárjai, azaz amikor kiborulunk...
- Bluetooth hangszórók
- Milyen notebookot vegyek?
- Androidos fejegységek
- További aktív témák...
- ASRock B550 PG Velocita + Ryzen 5 3600 + 32GB (4x8GB) DDR4 3600Mhz CL18
- Philips 58PUS8505 Smart LED Televízió,146 cm, 4K Ultra HD ,Android, Ambilight, HDR10+ KIJELZŐHIBÁSAN
- Canon EOS 250D kiegészítőkkel, táskával (CSAK 200 expoval !!! )
- Lenovo Legion Go 512GB + rengeteg extra!
- Bivaly erőmű Lenovo P1 G3 (Core I9 8mag/16 szál 32Gb DDR4 1Tb SSD 4Gb Nvidia) MAGYAR laptop eladó!
- BESZÁMÍTÁS! 1TB Corsair MP700 NVMe SSD meghajtó garanciával hibátlan működéssel
- Lenovo ThinkPad L16 Gen 1 - 16" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
- Bomba ár! HP EliteBook 830 G7 - i7-10GEN I 16GB I 512GB SSD I HDMI I 13,3" FHD I Cam I W11 I Gari!
- SzoftverPremium.hu
- Bomba ár! Lenovo ThinkPad T480s - i7-8GEN I 16GB I 256GB I 14" WQHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest