Már nem tekinthető biztonságosnak az SHA-1 hashelés
2015-10-09T13:22:17+02:00
2015-10-25T11:32:13+01:00
2022-07-22T04:03:21+02:00
  • Nem csak láttam, hanem rákerestem, letöltöttem, és kipróbáltam! Tényleg 1-3 másodperc alatt sikerült.
    Már nem emlékszem pontosan, de valami teszt-sor, vagy bug lehetett benne, mert ha jól emlékszem, minden archívumot a crack után valami egyszerű karakterrel is meg lehetett nyitni. (Azt hiszem egy "." pont)
    DE most látom, hogy a 9.3x alpha változat óta sokat fejlesztették tovább! Főleg idén. Tehát simán elképzelhető, hogy azóta kijavították a mostani bétában.
    http://www.7-zip.org/history.txt
    végigolvastam, és nem látok konkrét erre vonatkozó bejegyzést, de nem is túl valószínű, hogy ezt a fejlesztő annyira hirdetné utólag. Inkább csak a "some bug fix" valamelyike lehet, ha valóban javítva lett.
    Ha megtalálom valahol azt a crack-et, amivel teszteltem, akkor felrakom valahová.

    Továbbá az is fontos, hogy mindig legyen a "fájlnevek encryptelése" opció (vagy hogy hívják pontosan) is megadva tömörítéskor, mert különben abból simán visszafejtik.
    Mutasd a teljes hozzászólást!
  • Hol láttad az, hogy ilyen könnyű feltörni az újabb 7zip jelszavait? Tudtommal AES-256-ot használ, ami azért nem egy kispistike algoritmusa. Csak azért kérdezem, mert én simán Bétát használok de még nem hallottam ilyenről (pedig most direkt rákerestem). Kipróbálnám csak az érdekesség kedvéért :D
    Mutasd a teljes hozzászólást!
  • Amúgy ha már jelszó-biztonságról beszélünk.
    Mennyire könnyű feltörni egy 7zip jelszó-védett állományt?
    (ami a régi "stable" verzióval van tömörítve, mert köztudottan az újabb egy hiba miatt max 3sec. alatt törhető...)

    Jól számolom mondjuk 9 karakter esetében ez:
     92^9 jelszó ... amit ha egy EZ a benchmark szerint 2GPU próbálgat végig 110K/s sebességgel >> akkor 136110 év kell.
    Na de mi a helyzet, ha bérel az ember CPU időt valamely szerver-parkon?
    Mutasd a teljes hozzászólást!
  • @mimrock
    Nagggyon szépen köszönöm !!!
    A Delphi-s bcrypt tökéletesnek tűnik, a C#-osat még alaposabban meg kell vizsgálnom.
    Az Apache-port-forward pedig zseniális ötlet! Nem is tudtam, hogy ilyet is lehet.
    Ezzel egy gyors megoldást biztosítanék, nem kellene az indy-https-sel kísérleteznem.

    @Sting
    Értem, és tartottam valami ilyesmitől. Köszönöm a hozzászólásod.
    Mutasd a teljes hozzászólást!
  • Az általad írt saját "manipuláció"-knak, "megvariálás"-oknak semmi értelme, sőt, csak gyengíted velük a kódolást, csökkented az entrópiát. A hash-algoritmusoknak pont az a lényege, hogy maximalizálják az entrópiát - te pedig a hashek utólagos szorzásával, osztogatásával gyakorlatilag csak rontani tudsz ezen, könnyíteni tudod a törést. Tök függetlenül attól, hogy milyen és hány műveletet alkalmazol rájuk.

    A jelszavak HTTP-s weblapokban történő hashelésének szintén semmi értelme nincs. Az alapprobléma itt a kommunikációs csatorna megbízhatatlansága - ezzel összefüggésben pedig a megoldás a megbízhatóvá tétele. Amit adott esetben a HTTPS alkalmazása jelent - ahogy azt már többen is megállapították.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy a https gyakorlatilag az egyetlen lehetőséged arra, hogy egy webes alkalmazást megvédj attól, hogy a http-n közlekedő adatokat illetéktelenek lehallgassák. Magad semmiképp se találj fel ilyen célra protokolt, de a szakemberek szerint a böngészőben futó javascript eleve alkalmatlan erre a célra. Ha a kliens nem webes, hanem kizárólag c#, akkor persze vannak lehetőségeid a httpsen túl is, de ennek utána kell olvasnod. A lényeg, hogy valami bejáratott libet használj, és ne valami saját fejlesztést.

    A https esetén a certiket csak a szerveroldalon kell feltelepíteni, és csak a webszervernek kell tudnia róla, a delphinek nem. Ezt úgy tudod elérni, hogy feltelepítesz egy webszervert(Apache, nginx, IIS, mindegy), és megmondod neki, hogy bizonyos kéréseket továbbítson a delphinek localhostra, egy másik portra. Így a delphi szerver sima http kérésekre fog válaszolni, viszont a webszervered biztonságos, https kapcsolatot fog létrehozni a klienssel. Olyan pedig a világon nincsen, hogy a c# akármelyik http libje ne legyen képes https kliensként működni.

    A hashel kapcsolatben pedig ezeket találtam:
    bcrypt delphihez:
    JoseJimeniz/bcrypt-for-delphi

    Soha nem fejlesztettem c#-ban, pláne nem mobilra, de biztosan van valami megoldás. Ez például működik?
    http://bcrypt.codeplex.com/
    Mutasd a teljes hozzászólást!
  • Köszi, megfontolom, bár ezen az úton már próbáltam járni, és nem volt megoldható 2 okból:
    - dll-ek és certificate-ek telepítése nem megoldható minden egyes Delphi-s program mellé és bcypt-es algoritmust nem találtam még sima ".pas" fájlosat
    - a kliens C# -ból androidra/iphone-ra fordított klienshez még kevésbé :(
    Mutasd a teljes hozzászólást!
  • Szia,

    Szerintem nem igazán jó a koncepció. A HTTP lehallgatása ellen a https protokoll használatával és a megfelelő tanúsítványokkal tudsz védekezni, ezt viszont intézi a webszerver (ha megveszed a tanúsítványt, és beállítod). Az alkalmazáslogikában szerintem nem igazán van helye lehallgatás-elleni védelemnek, a jelszavak (a https-t leszámítva) utazhatnak plain textben is.

    A jelszó hashelés elsődleges célja az, hogy ha esetleg beüt a baj, és már feltörték a rendszeredet, akkor csökkentse a károkat: meggátolja, hogy a bűnözők nagy mennyiségű jelszóhoz jussanak hozzá, amiket esetleg máshol is fel tudnak használni. Ennek fényében az egyetlen cél az, hogy a jelszó előállítása neked ne legyen túl lassú, a támadó viszont minél drágábban tudja őket végigpróbálgatni.

    Mivel a korábban emltett két elterjedt megoldás közül a bcrypt a régebbi, elterjedtebb, és szabványosabb, ezért azzal nagyobb esélyed van arra, hogy sikerül ekvivalens megoldást találnod c#-hoz és delphihez.

    Szóval én a helyedben a következőt csinálnám. A frontend-ről érkező jelszót mindenféle körítés nélkül, plain textben elküldeném a szervernek(ha ez zavar, akkor állíts be https-t). Aztán kerítenék egy delphi bcrypt libet, és megpróbálnám összelőni valamelyik c# bcrypt libbel. Ha megvan a nyerő páros, akkor a minden trükközés nélkül a plain text jelszót bcrypt-tel hash-elném, majd ezt menteném el. Egy másik függvénnyel az össszehasonlítás is megoldható lesz, neked semmivel, még a sózással sem kell törődnöd. A nehézségre kell egyedül figyelned: Ha túl kicsi, akkor nem elég biztonságos, ha túl sok, akkor lassú lesz a bejelentkezés.

    EDIT: Elkerülte a figyelmem, hogy már létezik az adatbázis. Így két lehetőséged van: Az egyik, hogy megtartod a korábbi logikát a webhez is, de ebben az esetben is csinálhatsz minden a szerveroldalon. Ennek az lesz a hátránya, hogy ha a támadók megszerzik a hash-eket, akkor legtöbb jelszót simán vissza fogják tudni fejteni. A másik lehetőség az, hogy a régi módszer mellé implementálod az új, bcryptes módszert is, és amikor egy user belép, akkor a jelszó pillanatnyi ismeretét felhasználva legyárthatod neki az új, biztonságos bcrypt hasht, a régit pedig kitörölheted. Ez utóbbival sokkal nagyobb bizontásban lesznek a felhasználóid jelszavai, cserébe viszont egy kicsit többet kell vele dolgozni az elején.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Engem is egy hete foglalkoztat ez a téma.
    Sokat megtudtam az általatok leírtakból és ez elgondolkodtatott.

    Jelenleg így tárolom a user-ek jelszavait az adatbázisomban, és ugyanazzel a módszerrel tervezek webes-kommunikációs csatornát felépíteni:
    (Mivel Delhpi7 és C# .NET2.0 között azonos eredményeket kell kapjak és ennek kikísérletezése is napokig tartott,
    hogy mind2 rendszer ugyanazt az eredményt kapja...)
    1. Fogom a user begépelt password-jét és generálok mellé egy random Int32-őt. (Nevezzük ez utóbbit "GenKód"-nak)
    2. A GenKód-ot manipulálom bizonyos szorzással, összeadással
    3. Összefűzöm a user-pass-t és a String-gé alakított, manipulált GenKód-ot
    4. Ennek veszem az SHA-512-jét, és BASE63 string-gé alakítom.
    5. Majd ismét manipulálom az eredeti GenKód-ot, és azt is újra hozzáfűzöm
    6. Ennek is veszem az SHA-512-jét
    7. Ezt eltárolom és mellé az eredeti GenKódot
    ...
    8. Webes-kommunikációkor ugyenezt a műveletsort még egy "Dátum-idő"-vel is megvariálom,
    amely minden HTTP lekérdezéskor változik.
    9. Ezután az így "biztonsággal?" átküldött jelszót használom a további kommunikációra.
    (HTTP-user-pass azaz Credentials + talán még a küldött POST-ok ezzel való encriptelése)
    >> ez utóbbi rész még nincs kész, most készülök felépíteni egy ilyen kom-csatornát.
    10. A GET függvényeknél pedig átküldött paraméterek alapján generálok egy ellenőrző SHA512 "CRC"-t,
    ami része a link-nek.
    Pl.: http://valami.dyndns.com:54321/letolt_userek?ido=2015.11.11_123456&c..

    Tehát ha jól értem a leírtakat, akkor ez a módszer pofon egyszerűen visszafejthető,
    ha :
    1. folyamatosan lefülelik a HTTP forgalmat az adott porton?
    (A jelszó-próbálgatás ellen írtam védelmet az Indy webszerverbe...)
    2. megszerzik az adatbázist tartalmát?
    Mutasd a teljes hozzászólást!
  • Egyetértek. Szerintem nincs olyan magyar kifejezés, ami egyetlen szóval ki tudná fejezni a lényeget a hash "törés / visszafejtés" kapcsán (mivel se nem törés, se nem visszafejtés).
    Mutasd a teljes hozzászólást!
  • Nem érted.

    De ertem, hogy mit mondasz csak nem ertek egyet a terminologiaddal. Akkor mar inkabb a megfejtes szot hasznalnam de az eleg esetlenul hangzik. Miert nem lehet a pontos terminologiat hasznalni ami az "utkozes kereses/talalat" lenne?
    Mutasd a teljes hozzászólást!
  • A valóság az, hogy a "visszafejtés" csak annyit jelent, hogy megállapítunk egy olyan bemenetet (az amúgy lehetséges számos vagy számtalan sok közül), amin az eredeti transzformációt, műveletet végrehajtva, azonos eredményt kapunk. Nem többet, és nem kevesebbet.

    Semmi jelentőssége nincs a kérdésnek, de a te általad leírt művelet a hash-ek esetében angolul preimage attack. Az eredeti cikkben viszont ún. freestart collision attackről van szó, ami az ütközések egy speciális típusát jelenti. Az SHA-1 preimage attack ellen viszont egyelőre teljesen biztonságos, szóval nem igaz az, hogy kifizetődő lenne a fenti értelemben vett "visszafejtés"
    Mutasd a teljes hozzászólást!
  • Nem érted.

    Pont azt bizonyítottam be az előbb, hogy a magyar "visszafejtés" szó nem implikálja az eredeti bemenet minden részletében tökéletes reprodukcióját. Ha nem így lenne, nem használhatnánk az angolul "reverse engineering"-nek hívott folyamat magyar elnevezéseként.

    De bizony használjuk. Sőt, gyakorlatilag ez "a" (az egyetlen) magyar szavunk annak leírására. Ebből pedig egyenesen következik, hogy nem helytálló az érvelés, ami szerint nem beszélhetünk "visszafejtésről" ha az eredeti művelet információvesztéssel jár. Mert a fordítás is gyakorlatilag mindig azzal jár, mégis az annak az úgymond "megfordítását"* jelentő művelet leírására is ezt a szót használjuk.

    Ezen az, hogy egy program visszafejtése nem feltétlenül azonos módon zajlik egy hash visszafejtésével (amit rajtad kívül senki fel sem vetett), nem változtat semmit. Főleg, hogy bizony azért legtöbbször a programvisszafejtés is éppen úgy, kvázi szótár-alapon történik, mint a hashek visszafejtése. A különbség csak a szótárak méretében és univerzalitásában van közöttük.

    A valóság az, hogy a "visszafejtés" csak annyit jelent, hogy megállapítunk egy olyan bemenetet (az amúgy lehetséges számos vagy számtalan sok közül), amin az eredeti transzformációt, műveletet végrehajtva, azonos eredményt kapunk. Nem többet, és nem kevesebbet.

    *Persze a "megfordítás" szó itt nem csak képzavar, de teljesen helytelen is - és ez az a pont, ahol ti is elbuktatok a félreértelmezésetekkel. Pont azért nem értitek azt, amit mondok, mert ti azt hiszitek, hogy a visszafejtés valamiféle megfordított, visszafelé futtatását jelenti a transzformációnak - pedig dehogy.
    Mutasd a teljes hozzászólást!
  • Ha a userek soha nem használnák újra a jelszavaikat, akkor nem lenne szükség jelszó hashelésre, tehát az egész téma okafogyott lenne.

    Ez így nem igaz.
    Mutasd a teljes hozzászólást!
  • A userek sajnos hajlamosak újrafelhasználni a jelszavaikat, ezzel nem tudsz mit kezdeni. Ha a userek soha nem használnák újra a jelszavaikat, akkor nem lenne szükség jelszó hashelésre, tehát az egész téma okafogyott lenne. Sajnos a userek felelőtlenek, és neked, mint programozónak van felelősséged abban, hogy a felelőtlenül viselkedő usereket a lehetőségeidhez képest védd a bűnözőktől. Ezért kell az elérhető legjobb hash algoritmusok közül válogatni, ha jelszót hashelsz.

    Ha SHA-t használsz, akkor nem az elérhető legjobb módszert használod, ezzel pedig kockára teszed azoknak a usereknek a biztonságát, akik - felelőtlen módon - több helyen ugyanazt a jelszót használják, valamint segíted azokat a bűnözőket, akik feltörték az oldalad.
    Mutasd a teljes hozzászólást!
  • azért, mert a paypal, email, netbank accounthoz is lehet ugyanaz a jelszava a usernek, mint a kicsi webshopba

    Ez nem az SHA hibája.
    Mutasd a teljes hozzászólást!
  • A válasz pedig az, hogy
    - Nem elég (többek között azért, mert a paypal, email, netbank accounthoz is lehet ugyanaz a jelszava a usernek, mint a kicsi webshopba - megtörik a webshopot, megfejtik az SHA-val hashelt jelszót, máris bukott a paypal is.)
    - A bcrypt nem jelent extra fejlesztési költséget (időt)

    Tehát az SHA használata jelszó-hashelésre hiba.
    Mutasd a teljes hozzászólást!
  • Az érdekesség kedvéért leírom, hogyan használják a hash-függvényeket jogosultság-ellenőrzésre (pl az APOP vagy HTTP.DIGEST esetén):
    1. kliens kapcsolódik a szerverhez
    2. szerver küld valami üdvözlő üzenetet a kliensnek, ami garantáltan egyedi (például dátum+idő+sorszám is van benne)
    3. kliens előállítja a userid+HASH(üdvözlő üzenet+jelszó) stringet; és elküldi a szervernek
    4. szerver előállítja ugyanezt, és összehasonlítja a két értéket: ha egyezik, akkor a kliens beléphet
    5. a haxor mindezt lehallgatja, és 'visszafejti' a hash-t, azaz talál egy x-et, amire a képlet azonos eredményt ad
    6. ha az tényleg a jelszó volt, akkor egy következő körben ő maga eljátszhatja a kliens szerepét
    7. ha nem, akkor nem
    Mutasd a teljes hozzászólást!
  • Nem tudom mi nem megy át

    A gond az, hogy a kérdés nem az volt, hogy a b/scrypt jobb-e az SHA-2/3-nál, hanem az, hogy elegendő-e általános célú jelszavak hash-elésére az SHA fejlettebb változatai?
    Mutasd a teljes hozzászólást!
  • Nem tudom mi nem megy át, ha gondolod kérdezz bátran, de a most felvetett észrevételeidre úgy érzem megfelelően válaszoltam az előző hozzászólásban. Azt javaslom, keress rá googe-ben arra, hogy bcrypt vs sha, hátha más szemszögből mások, érthetőbben el tudják magyarázni a koncepciót.

    Egyetlen olyan állításod volt, amire nem válaszoltam korábban, mégpedig pedig ez:

    Adatintegritás ellenőrzésre az MD5 is használható.

    Ez csak akkor igaz, ha nem egy tudatos támadó módisításait, hanem csak véletlen hibákat szeretnél detektálni.[1] De miért ne használnál inkább SHA-2-őt ebben az esetben is?

    [1] Crypto attack that hijacked Windows Update goes mainstream in Amazon Cloud
    Mutasd a teljes hozzászólást!
  • A jelszavak megfelelő védelme akkor is elvárható, ha csak egy seprűnyelekkel foglalkozó webshop user táblájáról van szó.

    Én se mondtam mást, csak azt, hogy a védelem mértéke a védendő jelszó "értékétől" függ. Katonai szintű biztonság kiverné a biztosítékot a seprűnyél webshop usereinél.

    bátran lehet őket használni arra, amire valók: adatintegritás ellenőrzése

    Adatintegritás ellenőrzésre az MD5 is használható.

    a támadó megszerzi a jelszavak hasheit, akkor ő nem vaktában fogja próbálgatni a stringeket, hanem van egy elképzelése arról, hogy milyen jelszavak gyakoriak.

    A gyakori jelszavakra bármilyen hash-hez készíthető szótár. Hiába bcrypt-ezed az "abrakadabra"-t, ha egy bcrypt szótárban a hash-e mellett ott van, hogy "abrakadabra".
    Ezért írtam a sózást, illetve az SHA-2-3-nak van jelszavazható/sózható fv-e is.

    8 karakteres jelszóból pedig kevesebb van, mint ahányféle kimenete lehet a hash függvényednek.

    Igen, de azért ez még mindig 200 billiónál is több, amiből persze sok lejön az ismétlés és egyebek miatt.

    A lényeg az, hogy olyan hasht használj, amit a szerverednek 1-2 tizedmásodperc kiszámolni,

    Ha 1 useres szerver lenne, akkor ok, de akkor nem szerver. Ennél sokkal gyorsabbnak kell lenni a multiuseres/jobos működés miatt.

    A bcrypt/scrypt amúgy automatikusan kezelik a sózást.

    Ahogy az SHA 256-512 is.
    Mutasd a teljes hozzászólást!
  • Egyrészt itt jelszavakról van szó. A jelszavak megfelelő védelme akkor is elvárható, ha csak egy seprűnyelekkel foglalkozó webshop user táblájáról van szó. Mégpedig azért, mert a felhasználók hajlamosak ugyanazt a jelszót használni máshol is, márpedig email cím alapján könnyű felderíteni a többi accountjukat, és kipróbálni a webshopból kinyert jelszavakat.

    Másrészt a hashekkel kapcsolatban valamit félreértesz.

    Az SHA családnak három csoportja van, az SHA-1(amiről a cikk szól), az SHA-2, es a Keccak, azaz az SHA-3. A leghosszabb változatok 512 bitesek. Az SHA-1 már nem javasolt, de az SHA-2 és az SHA-3 viszont kiváló algoritmusok, bátran lehet őket használni arra, amire valók: adatintegritás ellenőrzése, HMAC, stb.

    Sajnos a jelszavak hashelése az pont egy olyan terület, amire az SHA család by-design nem jó. Hiába jó kocsi a porsche 911 az autópályán, ekét húzni jobb a zetor. Ettől a porsche 911 nem rossz kocsi, csak nem ekehúzásra való, ahogy az SHA család nem jelszavak hashelésére.

    A legnagyobb választható hash-hossz 512 bit, és abban igazad van, hogy ez beláthatatlanul sok. Ennyi hasht legenerálni a világ összes számítógépével se lehetne. Csakhogy, ha van egy webshopod, és van benne 10 ezer regisztrált user, és a támadó megszerzi a jelszavak hasheit, akkor ő nem vaktában fogja próbálgatni a stringeket, hanem van egy elképzelése arról, hogy milyen jelszavak gyakoriak. Először kipróbálja a a gyakoribb jelszavakat, megcsinálja a hashüket, és összehasonlítja a a feltörni kívánt user hash-ével. Utána az összes szótári szót kipróbálja, majd a az összes szótári szó különböző eltorzítását, végül pedig brute-forceszal legenerál minden szóba jöhet 7-8 karakteres jelszót.

    8 karakteres jelszóból pedig kevesebb van, mint ahányféle kimenete lehet a hash függvényednek. Szóval nem a bitek száma a fontos, sőt: Ha minden userhez csak 100 jelszót tud kipróbálni, már akkoris lesz néhány user a 10 ezerből, akinek sikerül feltörni a jelszavát. Ha 1 milliót ki tud próbálni, akkor lehet, hogy a felhasználók negyedének sikerül megfejteni a jelszavát. Ha 100 milliárdot ki tud próbálni, akkor pedig a háromnegyedének feltöri a jelszavát.

    Ezért aztán az a cél, hogy a támadó minél drágábban, és minél lassabban tudja kipróbálgatni a jelszavakat. Nincs elfogadhatóan lassú, mert a legjobb hash is ad valamekkora esélyt a támadónak, ezért csak a legjobb megoldással szabad beérni. A bcrypt és az scrypt lassúak, és azt is megadhatod, hogy mennyire. Nyilván a szervernek maximum néhány tizedmásodperc alatt muszáj tudnia kiszámolni, különben lassú lesz a bejelentkezés, ez ad egy felső korlátot a nehézségre. A lényeg az, hogy olyan hasht használj, amit a szerverednek 1-2 tizedmásodperc kiszámolni, és a támadónak pedig minél nehezebb és drágább.

    A só pedig arra való, és arra jó, hogy külön-külön kelljen támadni a userek jelszavait. Tegyük fel, hogy a támadó költségkerete 100 millió hash kiszámolására elég összesen. A só arra jó, hogy ezt a 100 millió próbát meg kelljen osztani a 10 ezer usered közt, és ne lehessen egyszer kiszámolni egy potenciális jelszó hashét, aztán pedig összehasonlítani mindegyik userrel, hogy na vajon kiével egyezik. A bcrypt/scrypt amúgy automatikusan kezelik a sózást.

    Szóval a fentiek fényében az SHA nem jó jelszvakhoz, mert
    - Bármennyi bites, akkor is gyors. Egyetlen 100 ezer forintos videókártya is 5-10 milliárd jelszót ki tud próbálni 1 másodperc alatt, ezzel a jelszavak felét biztosan feltöri.
    - A sok iterációs SHA jobb, de nem jó, mivel hiába állítod kellően lassúra, ugyanolyan, szerveren mért sebesség esetén 1-2 nagyságrenddel olcsóbban lehet adott mennyiségű jelszót legenerálni egy videókártyával, mintha bcryptet, vagy scryptet használnál.

    Amúgy a php-nek van egy password_hash nevű függvénye, ami tökéletesen alkalmas jelszavak generálására, és egyszerűbb is, mint kézzel gyártogatni a rossz sha hash-eket. A pythonban ott a passlib, biztosan c#-ban is van egyszerű megoldás, szóval jelszavak esetében semmibe sem kerül a biztonság, nincs ok arra, hogy figyelmen kívül hagyjuk a fenti szempontokat.
    Mutasd a teljes hozzászólást!
  • A visszafejtes teljesen ertelmezhetetlen sha eseteben ugyanis amikor collisiont keresel sem az eredeti hashbol indulsz ki es probalod az alapjan megtalalni az utkozest hanem ~ random inputokat generalsz es varsz, hogy utkozzon. 
    Tehat: collision != decryption != reverse engineering.
    Mutasd a teljes hozzászólást!
  • Az sha1-el nem meretbeli problemak vannak, hanem az, hogy az egesz algoritmust(csaladot) arra terveztek, hogy gyors legyen(mivel nem jelszo hash-eles az elsodleges cel). Mig a bcrypt, scrypt pont ezt a hibat javitja.
    Mutasd a teljes hozzászólást!
  • Az elterjedt megoldások közül csakis bcrypt vagy scrypt jöhet szóba.

    Csak a Puffin adhat erőt és mindent lebíró akaratot.
    Az SHA elég nagy család (SHA512, SHA1024, SHA2048 is van) és lehet további tölteléket is hozzáadni, valamint sózással lehet biztonságosabb hosszra növelni az eredeti jelszót.
    2048 bit azért kicsit nagyobb falat, mint 160 vagy 128, egy akár több ezer magos GPU-nak is.
    Másrészt érdemes figyelembe venni, hogy nem katonai vagy banki adatokról beszélünk, hanem általános adatokról (pl. könyvelés, levelezés, ...), aminek az "értéke" jóval kevesebb feltörési értéket képvisel.
    Mutasd a teljes hozzászólást!
  • Keress rá, ha nekem nem hiszel.

    Az elterjedt megoldások közül csakis bcrypt vagy scrypt jöhet szóba. Az sha magában egyszerűen nem erre való. Egy iterációval számolva nagyon gyors, és simán végig lehet számolni majdnem az összes szóba jöhető jelszót, de sok iteráció esetén megvan az a probléma, hogy egy 200 dolláros processzor (amin a szervered számol) egy-két nagyságrenddel lassabban számolja őket, mint a támadó által fehasználható azonos árú videókártyák, így nem tudsz elég sok iterációt használni.
    Mutasd a teljes hozzászólást!
  • Nem. Te értelmezted helytelenül az adott fogalmat.

    Hiszen, mint leírtam, egy program visszafejtése (reverse engineering) alatt sem azt értjük, hogy karakterről karakterre pontosan visszaállítjuk a forrást. Sőt, még a forrás visszaállítása sem feltétlenül implikált a "visszafejtés" által. Csak valamiféle információkifejtés egy, az eredetivel lényegi működésében - de nem teljességében - azonos alternatíva konstruálásának céljával. Pont, mint egy hash, illetve annak visszafejtése esetében is.

    Amiről te beszélsz azt, - ahogy szintén már leírtam - úgy hívják, hogy "az eredeti/bemeneti adatsor megállapítása/rekonstruálása". Nem pedig úgy, hogy "a hash visszafejtése".

    Nem baj. Ma is tanultál valamit.

    Egyébként amikor írtam annyira tudtam, hogy valami okostóni bele fog kötni ebbe a cikkbe.... Igaz, én pont nem a "visszafejtés", hanem a "törés" fogalom használata kapcsán gondoltam, hogy majd jön valaki azzal, hogy a hash-t nem is lehet meg-/feltörni...
    Mutasd a teljes hozzászólást!
  • Akkor, azt hiszem, a lényeget illetően egyetértünk: a derék újságíró pontatlan kifejezést használt: feltörni-re gondolt, de visszafejteni-t írt.
    Mutasd a teljes hozzászólást!
  • A derék újságírót meg kellene kérni, hogy írja le százszor: hash-t nem lehet visszafejteni, mert információvesztő művelet.

    Némi fogalomzavarban szenvedsz. Amire te nyilvánvalóan célzol, az az, hogy nem lehet megkeresni azt a pontos bemeneti adatsort, amiből a hash-t generálták - mert, hogy ugyanaz a hash több különböző adatsorból is keletkezhetett. Ami azonban nem ekvivalens a "hash visszafejtése" fogalommal (mint ahogy egy program visszafejtése sem azt jelenti, hogy az eredeti forrást nyered vissza, betűről betűre pontosan). Utóbbi ugyanis csak az adott elemzés, támadás szempontjából lényeges karakterisztikák, illetve egy utóbbi tekintetben ekvivalensnek tekinthető variáns megállapítását jelenti.

    Pl. egy a belépéshez használható jelszó megszerzéséhez nem szükséges annak az eredeti jelszónak a megismerése, amit a felhasználó anno mondjuk regisztrációkor megadott. Hanem elég egy olyan jelszó megkeresése, ami ugyanazt a hash-t eredményezi, mint előbbi. Ezzel éppen úgy be lehet majd az adott - és minden, azzal egyező hashelést alkalmazó - rendszerbe is lépni, mint az eredeti jelszóval.

    Az aláírások meghamisításánál szintén nem szükséges az eredeti adatsor megismerése - főleg, hogy az általában már eleve ismert. Ehelyett itt pont az a lényeg és ami kihasználásra kerül, hogy nem lehet az eredeti adatsort egyértelműen "visszafejteni" (a te félreértelmezésedben értve ezt a szót), illetve, hogy több, különböző bemeneti adatsor is eredményezheti ugyanazt a hash-t. A támadás lényege itt a bemeneti adatsor olyan módon történő összeállítása vagy manipulálása, hogy az továbbra is az ismert hash-t adja eredményül.

    A lényeg, hogy egyik esetben sem probléma az, hogy a hash információvesztő művelet. Visszafejtése pedig nem az eredeti bemeneti adatsor megállapítását jelenti, hanem csak egy olyan adatsorét, ami az adott hash-t eredményezi. Ez mind a két fajta támadás alapja.
    Mutasd a teljes hozzászólást!
  • ha az sha1 nem lenne egyébként is alkalmatlan a jelszavak tárolására.

    Ha már ennyire tudod a tutit, akkor áruld el légy oly kedves, mivel érdemes jelszavakat "tárolni"?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd