- Több új játék támogatásával bővült az Intel APO
- Ulefone Armor Pad 5 Ultra - 1,8 kiló, vetíthet?
- Felvenné a Noctua kesztyűjét az ASUS
- Leiskolázná a mezőnyt az új Samsung csúcs-SoC
- Kormányok / autós szimulátorok topikja
- Milyen belső merevlemezt vegyek?
- AMD Navi Radeon™ RX 9xxx sorozat
- Felköszöntötte a tíz éves DirectX 12-t a Microsoft
- A Windows 11 nem akarja ránk erőltetni az AI applikációkat – vagy mégis?
- 3D nyomtatás
Ú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 meglepett
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.
É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 szintre
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
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
- Gran Turismo
- Futás, futópályák
- Kecskemét és környéke adok-veszek-beszélgetek
- One mobilszolgáltatások
- Több új játék támogatásával bővült az Intel APO
- Ulefone Armor Pad 5 Ultra - 1,8 kiló, vetíthet?
- Felvenné a Noctua kesztyűjét az ASUS
- PlayStation 3
- Leiskolázná a mezőnyt az új Samsung csúcs-SoC
- PlayStation 5
- További aktív témák...
- Lenovo ThinkPad X13 G2 13.3" -50% AMD Ryzen 5 Pro 5650U Hexa-core 16GB 512GB SSD FHD
- Gaming PC - R5 9600X,RTX 5070 12GB,32GB DDR5,1TB NVMe,850W
- Ultra PC - R7 7800X3D,RTX 5080 16GB,32GB DDR5,1TB NVMe,1200W
- Uhh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 32/1TB RTX A2000 4GB /1 Millió/
- Lenovo Legion 5 15ARH05H - Gamer Laptop
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4022
- HIBÁTLAN iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA -Kártyafüggetlen, MS3590
- Egyedi ékszerdobozka
- Lenovo A485 Ryzen 5 pro 2500U, 8GB RAM, 256GB SSD, jó akku, számla, garancia
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB DDR5 RTX 5060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
"


