- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali alaplapos kérdések órája
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Kezdő fotósok digitális fényképei
- Kivégzi a Firewire-t az új macOS verzió?
- Vezetékes FEJhallgatók
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Bambu Lab 3D nyomtatók
- Házimozi belépő szinten
Ú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
- Béta iOS-t használók topikja
- Exkluzív órák
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- iPhone topik
- Autós topik
- Hosszabb bemutatót kapott a The Blood of Dawnwalker
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Viccrovat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Szívós, szép és kitartó az új OnePlus óra
- További aktív témák...
- OnePlus Pad 2 + OnePlus Pad 2 billentyűzet + Extrák
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 4060/5060/4070/5070 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- HP EliteBook 855 G8, 15,6" FHD, Ryzen5 PRO 5650U CPU, 16GB DDR4, 256GB SSD, WIN 11, ( olvasd végig )
- Dell Precision 5520, 15,6" 4K/UHD Touch, I7-7820HQ CPU, 32GB DDR4, 512GB SSD, M1200 4GB VGA, WIN 11,
- Dell Precision 3561, 15,6" FHD, I7-11850H CPU, 16GB DDR4, 512GB SSD, T600 4GB VGA, WIN 11, ( olvasd
- Bomba ár HP Pro X360 11 G1 - Intel N4200 I 4GB I 128GB SSD I 11,6" HD Touch I Cam I W10 I Gari
- BESZÁMÍTÁS! Gigabyte A620M R5 7600 32GB DDR5 512GB SSD RTX 4070 12GB ZALMAN S2 TG EVGA 650W
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- Csere-Beszámítás! Olcsó RTX Gamer Laptop játékra! I5 11400H / RTX 3050Ti / 16GB DDR4 / 512GB SSD
- LG 65QNED87T / 65" - 164 cm QNED / 4K UHD / 120Hz & 3ms / HDR 10 Pro / FreeSync Premium / HDMI 2.1
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged