Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
- _subi_:
Bevezetés a Sphinx keresőmotor használatába 
Bártházi András:
Perl alapjai VII.- Fájlműveletek
Nagy Gusztáv:
Weblapok ergonómiája
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | 1 | 2 | 3 | 4 | 5 |
Nem
Ha így érthetőbb: léteznek
léteznek egy és kétirányú titkosító algoritmusok.
A kétirányú (mondjuk amit a PGP vagy mondjuk a lemeztitkosító szoftverek használnak) visszafejthető a megfelelő kulccsal, hiszen pont az a célja, hogy a "címzett", el tudja olvasni a kódolt adatokat.
Az egyirányú elsősorban arra való, hogy pl. jelszavakat titkosíts vele. Ezekhez (matematikailag is bizonyítva) nem létezik olyan módszer, amivel az eredeti szöveget visszakaphatod - kivéve a brute force. Ezek ismereteim szerint aláírás készítésre, jelszavak kódolására alkalmasak. (lásd még "hash"!)
Az md5 "visszafejthető", de csak az említett brute force eljárással, ami azt jelenti, hogy gyakorlatilag végigpróbálsz minden lehetséges stringet MD5-tel kódolva, hogy azonos eredményt kapsz-e. Másik általam ismert változat az ú.n. szivárványtábla módszer, ami gyakorlatilag azt jelenti, hogy többé-kevésbé ismert jelszavakra előre legenerálták valamikor az MD5 hash-t és csak végig kell nézni a táblázatot, van-e azonosság? Ha van, akkor nyertél, ha nincs, akkor goto 1, brute force.
Ezek ellen a szivárványtáblák ellen véd valamennyire az ú.n. sózás.
De ha jók az emlékeim, az MD5-tel az a baj, hogy a grafikus kártyák párhuzamos feldolgozását kihasználva, nagyon hamar törhetőek brute force segítségével is.
------------
Ha hülyeséget írtam, javítsatok ki! Korábban is hajlamos voltam ilyesmire, de ehhez a témához nagyon nem értek, csak a hónapokkal ezelőtt összeolvasott emlékeim alapján írtam.
"Ezekhez (matematikailag is
Ha a potenciális bemenetek száma nagyobb, mint az md5 kimenetek száma, akkor nyilván nem létezik olyan módszer, amivel az eredeti szöveget visszakapod (brute force-szal sem). Ha kisebb (jelszavak esetén ez pl. azt jelenti, hogy 25 karakternél rövidebb alfanumerikus jelszót keresünk), akkor elenyészően kevés kivételt leszámítva nem lesznek ütközések, és brute force-szal elvileg visszanyerhető a bemenet; a gyakorlatban tizenpár karakter felett a brute force már nem realusztikus.
Semmiféle matematikai bizonyítás nincs arra, hogy ne lenne a brute force-nál sokkal hatékonyabb módszer a bemenet visszafejtésére; egyszerűen nem ismerünk ilyet.
Hát ennek utána fogok nézni.
Ahogy itt valaki emlegette a maradékos osztás maradékából nem lehet megtudni a másik két tagot. Valami ilyesmi rémlik, de vagy tíz éve olvasgattam e témában, szóval akár igazad is lehet.
Ha a maradékos példánál
"25 karakternél rövidebb alfanumerikus jelszót keresünk" = a bemenet pl 0 és 10 között lehet.
Belátható, hogy viszonylag kevés ütközés lesz (4 db), így pl ha tudjuk, hogy az eredmény 4, akkor a bemenet biztosan 4 volt. MD5-nél annyival bonyolultabb a dolog, hogy csak valószínűleg fogjuk tudni a bemenetet megmondani, hiszen ahogy tgr írta: "25 karakter alatt elenyészően kevés ütközés lesz", tehát nagyon valószínű, hogy megtaláltuk az eredeti bemenetet (és nem egy olyan bemenetet, ami csak véletlenül ugyanazt a kimenetet adja).
Gondold végig
Albert Einstein – A speciális és általános relativitás elmélete.pdf MD5 ellenőrzőösszege 335e4e8dc230a84e2aaf4236e5270cdf.
Szerinted ebből vissza lehet fejteni a 40Mb-os dokumentumot?
A tisztánlátás kedvéért
h(x)=x mod k(maradékos osztás), pl hak=7, akkorh(1)=1,h(2)=2,...,h(6)=6,h(7)=0,h(8)=1,..... Ha tudod, hogy egy számnak a maradéka 7-tel osztva 3, attól nem leszel sokkal okosabb, hiszen nem tudod megmondani, mi volt az eredeti szám. Viszont könnyen tudsz olyan számokat mondani, ami 7-tel osztva 3-at ad maradékul.Ugyanez a probléma az MD5-tel is, ha ismert a kimenete (azaz a hash értéke), akkor relatíve gyorsan tudsz olyan bemenetet generálni, ami ugyanazt a kimenetet adja. Így az eredeti bemenet ismerete nélkül meg lehet kerülni a rendszert.
(nem, nem fejthető vissza)
Igen is meg nem is
Visszafejteni tehát igazából nem tudod, legfeljebb tudsz találni valamit, amihez ugyanazt generálja mint amit te szeretnél visszafejteni, egy ún. ütközést (de sosem lehetsz benne biztos, hogy tényleg az volt).
Persze ha tudod, hogy jelszóból lett generálva és azt kapod, hogy "majom123", akkor valószínű, hogy tényleg az volt az eredeti. De még ha nem is vagy biztos benne, akkor is tudod használni azokon a helyeken, ahol a tiszta md5 alapján ellenőriznek.
(Viszont ha egy másik oldalon mondjuk sha1 van md5 helyett, vagy md5(jelszó+"salt") az ellenőrzés, ott nem fog működni az amit találtál ha az nem az igazi, tehát pl. a gmail fiókja biztonságban marad.)
Kicsit talán off a kérdésem.
Van az említett
A brute force ellen mindenképp véd a só
Nem
Kiegészítésképp
Viszont kéegészítésképp, ugye mivel az md5 elég gyorsan számolható, a só ismeretében nem telik lehetetlenül sok időbe egy saját táblát generálni. Ezért érdemes esetleg minden jelszóhoz külön sót generálni amit vele együtt el lehet tárolni az adatbázisban.
Ha minden jelszóhoz más-más só tartozik, akkor mindegyiket külön kell brute force-olni, nem lehet egy táblából kinézni az egész adatbázist.
(Azt ugyebár - a fentebb említett módon - a legtöbb esetben tényleg lehet feltételezni, hogy ha megvan a hash, akkor megvan a só is, tehát nem sokkat árt a biztonságnak ha egymás mellett tároljuk őket rögtön.)
Ez is igaz, de
Generálhatod egy programozott logika szerint pl. egyéb felhasználói adatokból, azokat is szépen összekeverve, stb. Így már a forráskódodhoz kell hozzáférnie a hackernek ahhoz, hogy a "sózási logikát" megkapja. Ha a forráskódhoz meg hozzáfért - már nincs mit tenni.
Persze a forráskódot jó
Mondjuk ezt PHP esetén kicsit
A következtetés innentől
És az adatbázisod?
Hogy jön ez most ide? A
Vegyük észre ...
PHP -> forráskód hozzáférhető
Zend Guard
ionCube Encoder
Ezek használatának van valami
Fizetni kell értük. A Zendet
Fizetni kell értük Ez azért
Ez azért elég természetes. A szoftverek elég nagy részéért fizetni kell, de azért remélhetőleg többet keresel a szoftver használatával, mint amennyibe kerül.
Yepp, ha már szóbakerült
Csak ezért választani a Javat
Az encoder első körben
Egyszerűbb beleírni a
Van, aki nem használ
Másik oldalról pedig ha jól tudom, akkor ezek egyben opcode cache-ek is (de lehet, hogy rosszul tudom).
Hát verziókezelő nélkül
Ami egyébként még érdekes
Ami pedig a verziókezelő használatát illeti, van aki jegyzettömbbel kódol, van ki IDE-t használ. Izlések és pofonok...
Ami pedig a verziókezelő
Nyilván ez a végeredményen is meglátszik...
Ez miből következik?
Abból, hogy sokszor annyi idő
Vannak a notepad-nél többet
A hozzászólásban notepadről
A notepad++ pont ugyanolyan
IDE
IDE
Wikipedia - Integrated development environment
Én elég sokáig fejlesztettem
Azt viszont nem tudom elképzelni, hogy komoly fejlesztő Notepad-ot használna.
Azt viszont nem tudom
Definiáld a komoly fejlesztőt, és hogy Notepad alatt a Notepad melyik inkarnációját érted.
Azert a hasonlatod szerintem
Szvsz aki hajlandó fizetni
Miért baj az, ha valaki zárt
Végülis ez is egy üzleti
Ha nem tud többet fizetni,
Körül kell nézni a szoftver
Kiszolgáltatva lenni mondjuk
Emellett a webalkalmazásoknál jellemzően nem reális, hogy tizedannyiért eladod a használati jogot, mert a karbantartás és az új felhasználói igények folyamatos beépítése teszi ki a nagy részét a munkának. Nem nagyon fordul elő, hogy egy cég megvesz egy alkalmazást, ami a core business modeljének a része (mondjuk egy webshopot), és az aztán elüzemel évekig anélkül, hogy módosítani kéne.
Ismerősi körömben, ami most
Ezek miatt a szolgáltatások karbantartása és fejlesztése nem szokott gond lenni náluk. Az adatok exportálását pedig bárki kérheti, amit akár kézzel, akár pedig programozottan is el lehet végezni.
Továbbá azt, hogy mi a jó üzlet – és ezt minden tisztelettel mondom –, kétlem, hogy a weblabor fórumára írók nagy többsége meg tudná ítélni. Azt meg tudjuk mondani, hogy az md5-öt vissza lehet-e fejteni vagy sem, mert ebben van gyakorlatunk, ezzel foglalkozunk legalább napi nyolc órában, de üzleti tapasztalata nem hiszem, hogy sokaknak van.
Az üzlet az egy olyan valami,
Nincsen olyan, hogy jó vagy rossz üzlet. Élethelyzetek, nézőpontok és értékrendek vannak, melyek mentén kezdvezőbb vagy kevésbé kedvezőbb lehetőségekről beszélhetünk. Hogy a külső szemlélő mit lát, mit ítél meg a saját nézőpontja és értékrendje alapján, teljességgel lényegtelen.
De van, szerintem
Véleményük - ahogy te is írod - részben szubjektív az adott üzletről.
Ha azonban mindegyik fél elégedett az üzlettel, akkor azt igenis jó üzletnek nevezhetjük. (És vice versa.)
Ebből a szempontból lényegtelen a "külső szemlélők" álláspontja, főként azért, mert javarészt nem látnak bele teljesen az üzletbe (lévén üzleti titok).
Tehát szerintem nagyonis létezik egyetemleges értelemben is jó és rossz üzlet. (Természetesen minden egyénnek a saját szemszögéből nézett jó és rossz a legmérvadóbb, azt nem vitatom.)
Más szint
Azért más szint, hogy fájlok tartalmához hozzáférünk a szerveren, vagy hogy kódot tudunk futtatni rajta.
Na jó, akkor szakértek...
Nézd meg a crypt függvény működését, különös tekintettel az általa visszaadott értékre! ;)
Konkrétan arra céloznék, hogy a visszaadott, tárolandó értékben benne van a só értéke.
Mivel a sózás a szivárványtáblák elleni védelmen túl semmi plusz védelmet nem ad, nincs értelme rejtegetni. Az is elég, ha minden tárolt jelszóhoz másik sót használsz, nyugodtan tárolhatod a jelszóval együtt.
Amiről te beszélsz, az már nem a sózás, hanem a két jelszavas beléptetés, amit eddig viszonylag kevés rendszeren láttam. Használni meg talán egyetlen helyen, ott is feleslegesen. :)
Peppernek hívják, és nem kell
A peppernek van haszna
Elég hash(pepper+password, salt)-ot használni. Az algoritmus szinte mindegy is, hogy mi szerintem, amíg a peppert nem szerzik meg, addig kevesek a dekódoláshoz. Vajon ismert jelszó és salt alapján meg lehet mondani a peppert?
Szivárványtáblát semmi
Szivárványtáblát ma egyébként se lenne értelme használni. A jelszótörésnél végső soron az a korlát, mennyi pénzed van rá. Ha elég pénzed van, vehetsz több számítási kapacitást, vagy több tárhelyet, amin letárolod a kevesebb számítási kapacitással hosszabb idő alatt kinyert hashtáblát; a közelmúltban a számítási kapacitás ára sokkal gyorsabban csökkent, mint a tárhelyé, úgyhogy kifizetődőbb azt venni, és on the fly számolni a hasheket.
A pepper egyszerűen arra való, hogy eggyel több helyet kelljen feltörni ahhoz, hogy a jelszóhashelő algoritmust reprodukálni tudja a támadó. Ha az adatbázishoz hozzáfér, de a fájlokhoz nem, akkor a pepper megvéd. A gyakorlatban azért van kevés haszna, mert az ilyen szituáció ritka: SQL injection ellen könnyű védekezni, úgyhogy ha valaki elvitte az adatbázisodat, azt valószínűleg úgy csinálta, hogy be tudott jelentkezni a szerveredre, és akkor elvitte a forráskódot is.
és akkor elvitte a
Ezért kell fordított nyelvet használni :)
Ha beszórsz egy 32 karakteres
Ilyenkor külön minden salt-ra csinálni kell szivárványtáblát, és egyesével megnézni a jelszót. Ha nem tudják az algoritmust, akkor így esélytelen, ezért szoktak pl ciklusokat csinálni md5(salt.md5(salt.password)), stb...
A brute force ellen az véd, ha erőforrás és/vagy időigényes a hash készítése, pl blowfish algoritmusnál ez van. Ezeket direkt ilyen célra találták ki, az md5 és sha1 nem ilyen, azok nagyon gyorsak... Egyszerűbb védekezés brute force ellen, ha 50 db egymás utáni sikertelen próbálkozás után töröljük a jelszót és erről emailt küldünk, vagy ideiglenesen zároljuk a fiókot jelszavas belépésre. A cookiek, linkek sokkal hosszabb karakter láncokat tartalmaznak, mint a jelszavak, azok ellen nincs esélye a brute force-nak.
A brute force tipikusan abban
A brute force tipikusan abban
Adatbázis nem csak sok
(bizonyos szempontból a /etc/passwd-/etc/shadow duó is adatbázis.
És épp elég, ha hozzáférnek az adatbázisban tárolt usernevekhez és kódolt(már ahol :( ) jelszavakhoz, ha nem elég jó a kód/hash.
Gondolom egyszerűen
Az md5 nem titkosító, hanem
Egy hash algoritmus két feltételnek kell hogy megfeleljen:
1. Nem "hamisítható", vagyis tetszőleges hash értékhez nem lehet (ill. igen nehéz) olyan adatot előállítani, ami az adott hash-t eredményezné. Ennek az MD5 máig ellenáll.
2. Két különböző bemenő adat mindig különböző hash-t ad. Ez az, aminek már nem áll ellen, mert találtak ún. ütközést, és van is program, ami pár perc alatt generál ilyet.
A nagy baj akkor lenne, ha az első feltételnek nem felelne meg, mert akkor sok protokoll használhatatlanná válna. A második feltétel megdőlését a gyakorlatban támadásra nem lehet kihasználni, mindenesetre azért jelzi, hogy az algoritmus sebezhető, ezért érdemes váltani olyanra, ami ellenáll mindkét feltételnek, pl. SHA-ra.
Ütközés alapú támadások
A Flickr-t például pár éve
Igazad van, úgy látszik
Az egy népszerű legenda, hogy
A rövid válasz az, hogy nem
- lehet-e találni két olyan szöveget, aminek ugyanaz az md5 hashe? (Lehet; ezt szokták leegyszerűsítve úgy megfogalmazni, hogy az md5-öt megtörték. "md5 collision attack" kulcsszóra guglizva tetszőleges mennyiségű információt lehet találni róla.) Ez tipikusan a digitális aláírásoknál érdekes.
- ha nagy vonalakban tudod, hogy néz ki az eredeti szöveg (pl. csak számokból és betűkből áll, és kevesebb, mint 10 karakter), akkor ki tudod-e találni, mi volt az? A válasz az, hogy csak úgy, ha végigpróbálgatod az összes lehetőséget, hogy ugyanazt a hasht adja-e; de az md5 nagyon gyorsan számolható, ezért gyakran ez elég is. (Pl. az összes <8 betűs szót percek alatt végig lehet próbálgatni.) Ez tipikusan a jelszavak tárolásakor érdekes.
És ha ciklusban
Ha jól állítod be a
A bcrypt annyival jobb, hogy olyan műveleteket használ, amiket nem lehet egy az egyben regiszter-műveletekre lefordítani, ezért csökkenti valamivel a GPU-nak a CPU-val szembeni relatív előnyét.
Okés.
Még az is elég kevésnek
És itt jön képbe a különböző algoritmusok különböző hatékonysága GPU-n: a GPU-s törés ellen kifejlesztett algoritmusok (bcrypt, scrypt, sha*crypt) esetében ami neked 10ms, az nagyságrendileg a támadónak is annyi, sima md5 iteráció esetén van vagy 4 nagyságrend előnye, mert egy GPU annyival gyorsabb, mint egy CPU.
Hát akkor az md5 nem sokat
Saját gépen az md5 13333 ciklussal 30 msec körül van, ahogy nézem a szerveren is hasonló...
Alapvetően kétféle hash
Persze lehet md5-ből iterálással erősebb eljárást csinálni (ezt teszi a PBKDF2 is), de általában nem jó ötlet saját algoritmusokat kitalálni, ha van standard; erős építőkockákból is össze lehet rakni gyenge végeredményt, ha nem tudod, hogyan kell helyesen alkalmazni őket.
Standard jelszóvédő algoritmusból pedig nagyjából három van: PBKDF2, bcrypt, scrypt. (Elvileg a sha256crypt, sha512crypt is ilyen, de azok kevésbé népszerűek, és nem sokat tudok róluk.) Ebben a sorrendben egyre erősebbek (a PBKDF2 csak egy gyors hash iterálása pár finomsággal, a bcrypt iterációnként más-más műveletet végez, ezért sokkal kevésbé lehet GPU-n felgyorsítani, az scrypt tetszőlegesen sok memóriát igényel, ezért GPU-val vagy FPGA-val sem lehet sokkal olcsóbban számolni, mint CPU-val) és egyre kevésbé "állták már ki az idő próbáját" (a PBKDF2 elég régi és NIST certified, az scrypttel még inkább csak kriptográfusok játszottak eddig, nagy rendszerekben nem sokat használták); valamennyire ízlés dolga, melyik szempontot részesíti valaki előnyben, legtöbbször arany középútként a bcryptet szokták ajánlani.
Ja, én is a bcryptet látom
+1 tgr
Admin jelszó visszafejtése SQL
A programozó meghalt.
Nekem mindenhez teljes a hozzáférésem.
Szerver - Adatbázisszerver - sql - minden.
De a programozó admin jelszava titkosítva van az sql adatbázisban.
Bizonyos dolgokhoz meg csak azzal lehet hozzányúlni.
Ki lehet e nyerni valahogy a jelszót ?
Uj tema
Ha egyedi fejlesztesu a szoftvered es nem ertesz hozza, akkor viszont jobb, ha az Allas rovatba kuldod be, mivel valoszinuleg ugyis valakinek meg kell csinalnia helyetted.
Módosítsd
védelem
Szerintem a többség md5-öt használ, vagy sha1-et. A Bcrypt már jobb, igaz PHP libraryként elég lassú, de azt hiszem az új PHP-ban már natívan is benne lesz.
De ha ráérős vagy, kísérletezhetsz egészen eszement megoldásokkal, pl.:
- a jelszót kiírod egy fájlba és abból csinálsz egy hash-t.
- fogsz egy 1 bájtos fájlt, azt bezipeled, a zipet jelszavazod, majd az így kapott fájlra tolsz egy fájl hasht.
Lassú, fölösleges, de viccnek és gyakorlásnak jó.
És fájl hashaléshez szintén ne MD5 legyen, hanem mondjuk Haval:
A Bcrypt by design lassú, az
Login
Nyilván lehet állítani, hogy
ha kód is van...
Ennek mi értelme? :)