Kitalálója szerint senki ne használja már többet az MD5-öt!
2012-06-08T10:40:33+02:00
2012-06-11T19:36:02+02:00
2022-07-24T01:07:22+02:00
  • Hali!

    ... már érthetőbb, hogy miért is felesleges az a hash Sting szerint


    Már csak az kellene megmutatnod, hogy Sting mikor és hol mondott ilyet. Enélkül ez nem más, mint - a szokásos céltalan és értelmetlen, ámde tőled megszokott - pufogás, semmi több.

    Mutasd a teljes hozzászólást!
  • felesleges az a hash Sting szerint

    Szövegértésből egyes. Sőt, egyes alá.
    Mutasd a teljes hozzászólást!
  • Jó hogy mondod a proghut, már érthetőbb, hogy miért is felesleges az a hash Sting szerint
    Mutasd a teljes hozzászólást!
  • Hát kisebb cégeknél kb. minden programozónak és teszternek kerül a kezébe legalább egy másolat legalább egy adatbázisból, amelyben lehetnek autentikációs adatok. Ugyanakkor éppen ezen emberek többségének nincsen hozzáférésük az éles szerverhez/szerverekhez, hanem az a rendszergazdának van. Szóval nem azt mondtam, hogy a titkárnő nézegeti azt a táblát, hanem hogy a programozóknak lehet hozzáférésük egy másolathoz legalább, ez egy teljesen reális szkenárió, tapasztalatból írom. Nyilván egy becsületes programozó ezzel sosem él vissza, de nem csak becsületes programozók vannak.

    És azt cáfolom, amit írtál, amellyel azt állítottad, hogy azoknak az embereknek, akik látják a táblát, van más lehetőségük is elérni a jelszavakat. Nem, nem mindegyiknek van.
    Mutasd a teljes hozzászólást!
  • Nem jelent komoly kockázatot a dolog. Túl sok biztonsági résnek kell lennie, hogy valaki megtudjon egy kulcsfontosságú jelszót pl egy MySQL adatbázisból.

    1.) Komoly SQL-sebezhetőség, ami már önmagában is nagy vétek
    2.) "sótlan" jelszavak vagy kiolvasható só.
    3.) egy hét a támadónak, aki mellesleg nagy teljesítményű processzort használ

    Emellett bárki bármikor módosíthatja valamelyest az elkészült md5 hashet, és mindjárt nem lehet tudni, hogy pontosan milyen eljárással készül a kódolt üzenet. Például atbash hexa számjegyekkel. Egyszerű és nagyszerű.
    Mutasd a teljes hozzászólást!
  • Most azt leszámítva, hogy akinek nincs feltétlenül szüksége rá (pl. teszternek, programozónak), annak miért is adnának ki valódi, éles authentikációs adatokat - tehát hogy az a szkenárió, amit leírsz, a valóságban nem ill. igen ki valószínűséggel létezik egy komoly projektnél -, tulajdonképpen mit is akartál a felvázolásával megerősíteni vagy cáfolni?
    Mutasd a teljes hozzászólást!
  • Akkor én nem mondom meg, hogy mikor váltottam jelszót a proghun
    Mutasd a teljes hozzászólást!
  • Egy példa, programozóként hozzáférek egy ügyfél adatbázis másolatának felhasználó táblájához, de ettől még nem férek hozzá az éles adatbázishoz, valamint mások is nézik a kódot, tehát a hátsó kapuval is lebuknék (főleg ha svn-ből látszik, hogy én voltam), akkor ha a gyűlölt szomszédom jelszava az adatbázisban van, legegyszerűbb módja hazavinni az ő hashét, visszafejteni. Majd ha máshol is ugyanez a jelszava, és ott használom, az eredeti szoftverben nem, még csak nem is fognak rám gyanakodni. Ha a hash visszafejtése 5 év lenne, addigra már nem ugyanaz lenne a jelszava valószínűleg.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Mondjuk arra kíváncsi lennék, hogy mondjuk egy 10.000 soros usertábla adatait megszerezve, leszűrve úgy, hogy csak a népszerűbb szolgáltatóknál regisztrált email-címes sorok maradjanak, majd egy scriptel belépegetve erre a címrekre a táblázatban szereplő jelszóval, hány találat lenne...
    Mutasd a teljes hozzászólást!
  • Amivel nem cáfolod állításom lényegét, miszerint egy velejéig gonosz ember vagy.

    Amúgy, ja, igazad van.
    Mutasd a teljes hozzászólást!
  • Ezeket legegyszerűbben úgy kerülöd le, hogy:
    1. Az user nem adhatja meg a jelszavát, hanem kap egyet, időnként cserélve.
    2. A véletlen jelszó generálása után a generáló szoftver megnézi a legfrissebb md5 decrypter adatbázisokban, hogy a generált jelszó hash-e megvan-e. Ha igen, akkor nyilván másikat generál neki. Random jelszónál ha mondjuk md5-öt gyártasz belőle, akkor 1000-ből 999x nem lesz benne.


    Amit írsz, az már a security vs. usability kérdéskörét feszegeti. Nem csoda, hogy kis számú esettől eltekintve nem így keletkeznek a jelszavak.

    Megjegyzem, hogy salt nélkül főleg MD5-el nem illik mostanában dolgozni. Minimum _jelszóhossz_ és _komplexitási kritériumok_ (minimum hány különböző kategóriába eső karakter) alkalmazása _sózva_ _SHAn_ hash-el szokott a nyerő lenni.
    Mutasd a teljes hozzászólást!
  • e27dae7c19089f8f8c547a3d8f3c36de
    Ez mi? md5decrypter.com nem tudja.
    Mutasd a teljes hozzászólást!
  • És egy Ugandai hackernek hogy fogja feldugni s.ggébe a gumibotot a security szerinted? Mert a belsős próbálkozónak simán.

    És akkor ebből nem az következik, hogy az adatbázist (és benne a jelszavakat) nem elsősorban a belsősöktől kell védeni (mert hogy ők könnyen felelősségre vonhatók ha visszaélnek az információkkal), hanem a külsősöktől? Dehogynem. Akkor ezzel nem megint pont magadat és a saját állításaidat sikerült cáfolnod (ti. azt hogy bármiféle szerveroldali kódolás - pl. hashelés - elsősorban nem a külsősöktől, hanem a belsősöktől lenne hivatott védeni)? De, megint.

    Az adatbázist lehet olvasni, igen. És akinek fotografikus memóriája van, az sokat meg is tud belőle jegyezni.

    A papírt, a kamerás mobiltelefont, a digitális adathordozókat és a rádiófrekvenciás kommunikációt pedig - mint tudjuk - még nem találták fel, hanem csak a jövő évezredben fogják. Majd. Így fotografikus memória hiányában nagy mennyiségű információ nem szivárogtatható ki. Vagy mégis? Bár nem is értem ennek mi köze van ahhoz, amiről itt szó volt.

    >>Normális helyen az éles rendszernél a rendszer beállításait és persze magának a kódnak a változásait senki se módosíthatsz egyedül, ad-hoc módon.<<<
    "Ki mondta, hogy módosítja"
    "Azért nincs így, mert a jelszó hiába van az adatbázisban szupertörhetetlen hasheléssel kódolva tárolva, az adminisztátor bármikor meg tudja oldani annak plusz naplózását akár regisztrációkor, akár a későbbi bejelentkezésekkor (webszerver vagy akár csomagszintű naplózással is)."

    Szóval azt akarod mondani, hogy szerinted valamilyen hálózaton áramló adat leghallgatásához, lenaplózásához feltétlenül valamiféle kódmódosítás szükséges? Kérlek mondd, hogy csak műkedvelő amatőr vagy, és nem gondolod szakembernek (vagy akár csak közepesen tájékozott felhasználónak) magad! Ugye nem?

    Egyébként mondd, ezzel az állandó alpári fogalmazással és káromkodással mit próbálsz kompenzálni? Mármint az intellektuális deficiten túl. Vagy csak azt?
    Mutasd a teljes hozzászólást!
  • nem neked szól, de talán ehhez tartozik:

    ha valakit érdekel, akkor esetleg nézzen utána a "Distributed Rainbow Table Project"-nek
    Mutasd a teljes hozzászólást!
  • Amik md5-re vannak letölthető adatbázisok azok 2 módon képződnek:


    Inkább három mód az a kettő... vannak elég nagy szivárványtáblás adatbázisok is. Van egy 9Gb-os szivárványtáblás md5 hash táblám, benne 8 karakter hosszúságig az ascii tábla összes gyakran használt karakterével előállított összes lehetséges karakterlánc és md5 hash-e. Egy 45Bk%/.4 bonyolultságú jelszó feltörése kb. 3 perc vele.
    Sózás nélkül a generált jelszavas megoldásod semmire nem jó, csak az usert szívatod vele.
    Mutasd a teljes hozzászólást!
  • A belsősök és a külsősök közül nem a belsősöknek egyszerűbb a védelmi vonalakat megkerülni, kiiktatni (amik közül soknak eleve mögötte vannak, mint pl. a tűzfal)?


    És egy Ugandai hackernek hogy fogja feldugni s.ggébe a gumibotot a security szerinted? Mert a belsős próbálkozónak simán. Az adatbázist lehet olvasni, igen. És akinek fotografikus memóriája van, az sokat meg is tud belőle jegyezni. Nem véletlen, hogy a felvételik során ilyen embereket kiszűrik, hogy ne kerülhessenek bizalmi pozícióba.

    Nade veled vitatkozni, az olyan mint sajtreszelővel rejszolni - mondaná Ford Fairlane. Egyszerűen elképzelsz valamit, aztán simán ignorálod a tényeket, mert ha valamit elég sokszor leírsz, arról azt hiszed, hogy igaz is. Pl:

    "Ki mondta, hogy módosítja"
    "Azért nincs így, mert a jelszó hiába van az adatbázisban szupertörhetetlen hasheléssel kódolva tárolva, az adminisztátor bármikor meg tudja oldani annak plusz naplózását akár regisztrációkor, akár a későbbi bejelentkezésekkor (webszerver vagy akár csomagszintű naplózással is)."
    Hogy is hívják azt a professzort, aki mindig elkeveri a cuccaidat?... Jaaa, Alzheimer!
    Mutasd a teljes hozzászólást!
  • Nem, az pont annyi variációt ír, amit írtam. 26 kisbetű, 26 nagybetű, 10 számjegy - ez 1 karakteren 62 variáció. 8 karakteren meg 62 a 8-adik hatványon. Md5 szórásra most nem írok tesztert ha nem baj - 256 a 16. hatványon lehetősége van - szerintem szór annyira jól, hogy nem lesz túl sok 8 karakteres jelszó, amelyiknek ugyanaz lenne az md5-je.

    Amik md5-re vannak letölthető adatbázisok azok 2 módon képződnek:
    1. értelmes szavak adatbázisból generált jelszavak
    2. okosok által webes md5 encrypterbe beirkált jelszavak.

    Ezeket legegyszerűbben úgy kerülöd le, hogy:
    1. Az user nem adhatja meg a jelszavát, hanem kap egyet, időnként cserélve.
    2. A véletlen jelszó generálása után a generáló szoftver megnézi a legfrissebb md5 decrypter adatbázisokban, hogy a generált jelszó hash-e megvan-e. Ha igen, akkor nyilván másikat generál neki. Random jelszónál ha mondjuk md5-öt gyártasz belőle, akkor 1000-ből 999x nem lesz benne.
    Mutasd a teljes hozzászólást!
  • sting egy velejeig gonosz ember, igy nagyon nem orulnenk neki, ha plaintextben latna a jelszavunkat a pehapemajszikulban.

    A nagyon gonosz ember hiába tárolja nem-plaintextben a jelszavad az adatbázisban, mert bármikor igény szerint kilogolhatná bejelentkezéskor azt. Hiszen az ott és akkor nem hashelve, hanem plaintextben kerül elküldésre a html formban - hiába is van az adatbázisban már csak hash formában meg, és hiába utóbbi képezi az authentikáció alapját. Ezért az, hogy hashelve van -e a jelszó az adatbázisban vagy sem, ebből a szempontból irreleváns. Ha akar a szervergazda és ugyanazt a jelszót használod nála is, mint máshol, vissza tud élni vele.

    ebben az esetben a hash a belsosok ellen is ved.

    Mint írtam, ezt nem vitatta senki. A vitatott állítás az volt, hogy kizárólag vagy elsődlegesen a belsősök - és nem pedig a kívülről érkező - támadások, adatlopások ellen lenne hivatott védeni a hash. Mert, hogy mint látod, a belsősök a hashelés ellenére is képesek lehetnek megszerezni a plaintext jelszavad viszonylag egyszerűen (amit más rendszerekbe belépésre is fel tudnak használni, ha ott ugyanazt a jelszót adtad meg), illetve jó eséllyel eleve meg tudják kerülni az egész authentikációt, és magában a rendszerben anélkül garázdálkodhatnak a nevedben, hogy a jelszavad ismernék.
    Mutasd a teljes hozzászólást!
  • az emberek tobbsegenek egy vagy ket jelszava van, amit altalaban a paypaltol lezdve a prog.hu-ig mindenhova megadnak. na most, mivel mi mindannyian tudjuk, hogy sting egy velejeig gonosz ember, igy nagyon nem orulnenk neki, ha plaintextben latna a jelszavunkat a pehapemajszikulban. viszont azt elhisszuk neki, hogy egy forum webszerver szekuritit be tud loni. ebben az esetben a hash a belsosok ellen is ved.
    Mutasd a teljes hozzászólást!
  • Ez persze nem így van. Ha az adatbázishoz hozzáfértek, akkor az esetek jelentős részében már pont lesz.rják a jelszavakat, mert direktben leszívják/módosítják az adatokat.

    Na, de nem a belsősöknek egyszerűbb és könnyebb az adatbázishoz direktben hozzáférni? A belsősök és a külsősök közül nem a belsősöknek egyszerűbb a védelmi vonalakat megkerülni, kiiktatni (amik közül soknak eleve mögötte vannak, mint pl. a tűzfal)? Dehogynem. De hát akkor nem pont nekik van kevésbé szükségük egyáltalán a jelszavakra ahhoz, hogy akár írják, akár olvassák az adatbázist közvetlenül? Dehogynem. Nem a belsősök azok akik könnyebben vissza tudnak élni a jelszavak nélkül is a rendszerrel és az abban tárolt jelszavakkal? Dehogynem. Akkor hogyan is lehetne igaz azon állításod, ami szerint "a jelszavak MD5 vagy bármilyen más egy irányú kódolással való átalakítása rohadtul nem a külsősök megfékezésére szolgál, hanem arra, hogy az adminisztrátorok ne tudjanak a felhasználói adatbázissal visszaélni"? A válasz persze az, hogy a fentiek értelmében ez az állításod egyértelműen nem lehet helytálló, sőt, pont az ellenkezője igaz.

    Akkor arról még nem is beszéltünk, hogy mennyire hatványozottan igaz ez, illetve mennyire hamis a te állításod az általad példaként hozott banki rendszerek esetében, ahol a belépési azonosítókat, PIN-kódokat és jelszavakat jellemzően a bank osztja ki. Így a belsős hiába is tudná elolvasni, kifejteni ezeket az információkat, mert ezekkel csak a saját rendszerébe tudna belépni - amihez viszont már eleve rendelkezik hozzáféréssel, hiszen így szerezhette csak meg a belépési azonosítókat. Tehát pont a bank az, ahol a belépési azonosítók kódolása, hashelése a legkevésbé érdekes a belsős visszaélések szempontjából, hiszen nála még egy hobbiweboldal is jobban vissza tud élni azokkal. Mert a hobbiweboldalon a felhasználó adja meg a belépési azonosítóit (email, nicknév, jelszó), amiket így az ottani admin valóban esetleg fel tud használni arra, hogy - ha a felhasználó balek volt, és ugyanezeket adta meg más oldalakon történő regisztrációkor is -, akkor más, tőle független szolgáltatásokba, oldalakra is belépjen a felhasználó nevében, az azonosítók azonosságát kihasználva. De a banknál ez a fentiek miatt teljesen kizárt. Tehát pusztán ezen szempontból a banknál még annyira sem fontos a belépési azonosítók hashelése a szerveroldali tárolásban, mint egy hobbioldal esetében.

    Természetesen ez is csak a pistike webdesign studió szintű cégeknél működik. Normális helyen az éles rendszernél a rendszer beállításait és persze magának a kódnak a változásait senki se módosíthatsz egyedül, ad-hoc módon.

    Ki mondta, hogy módosítja, ki mondta, hogy egyedül teszi, és ki mondta hogy ad hoc módon? Senki? Akkor miről is beszélsz megint?

    Igen, ezt mondják a dolgozóknak az IT vezetők. De ha össze tudsz adni kettőt meg kettőt, akkor rájössz, hogy ez a módszer ugyanolyan jól véd a belsős támadások ellen is.

    Itt megint meg kell kérdeznem, hogy: és ki mondta, hogy nem véd ellene? Minek írsz le evidenciákat? Vagy ez újdonság volt neked?

    "Ennek megint nem lenne semmi értelme ha így működne, hiszen a belsős támadások ellen ez nem véd. Az ugyanis aki az adatbázishoz hozzáférést tud szerezni (mert pl. admin, vagy mert exploitot tud futtatni a célgépen) jó eséllyel a gép memóriájához is ugyanúgy vagy még könnyebben hozzáférést tud szerezni"
    Mint mondtam: az megoldott, hogy amit módosítasz, az legális legyen (legalábbis értesüljenek róla, ha illegálisat tettél).

    1. Miért jössz a módosítás legalitásával, amikor ehhez semmit nem kell módosítani, csak olvasni kell? Módosítás, olvasás - nem ugyanaz, nem is hasonlít egymásra a két szó. Minek kevered össze őket?
    2. Az előbb azt állítottad, hogy az olvasást nem szokás naplózni. Akkor hogyan is értesülnek róla, hogy illegálisat tettél és kiolvastad a memóriából az adatokat? Hiszen szerinted nem is naplózzák (nem ám, hogy riasztanának miatta), nem? Megint ellentmondtál magadnak.
    3. Tudod mit jelent az "exploit" szó? Nem? Akkor nézz utána!
    Mutasd a teljes hozzászólást!
  • A nagy méret miatt alfanumerikus és egyéb a jelszavakban előforduló karakterekből álló string-ek hash értékeit szokták prekalkulálni rainbow table-be. Amit nem tudsz beütni a billentyűzeten, az nem lesz a jelszavadban. Lényegesen kevesebb variációt ad.

    Másik dolog a redukciós függények használata:

    Rainbow table - Wikipedia, the free encyclopedia
    Rainbow Tables - Part 1 (Introduction)
    Mutasd a teljes hozzászólást!
  • Nem tudom hogy az md5 mennyire jól szór, de 16 byteos, 8 karakter meg ugye 8 byte. 218340105584896 variációról beszélünk, ez 198.5 TByte lenne akkor, ha 1 jelszó-kulcs tárolását 1 byteon oldanád meg, tökéletes szórás esetén (vagyis minden jelszó különböző md5-öt adna). Szóval ezen emel az, hogy nem 1, hanem 8+16=24 byteon tudod tárolni egy párost (lehet persze huncutkodni, de nagyságrendileg ennyi), és ugye csökkent az, ha nem tökéletes a szórás. Szerintem azért a teljes lefedettséghez több kell pár GByteos hashnél (meg ugye az csak disken volna tárolva ami lassú, számoláshoz meg csak memoár kell, ami gyorsabb is, stb).
    Mutasd a teljes hozzászólást!
  • Az, hogy az adatbázisszerver mennyire törhető, és minden további amit ezzel kapcsolatban leírtál szinte teljesen irreleváns.

    Ez persze nem így van. Ha az adatbázishoz hozzáfértek, akkor az esetek jelentős részében már pont lesz.rják a jelszavakat, mert direktben leszívják/módosítják az adatokat. Szóval igen csak releváns az, hogy a db szerver mennyire hozzáférhető, és - mivel nem muszáj - így nem is szokták kitenni támadásoknak.

    Azért nincs így, mert a jelszó hiába van az adatbázisban szupertörhetetlen hasheléssel kódolva tárolva, az adminisztátor bármikor meg tudja oldani annak plusz naplózását akár regisztrációkor, akár a későbbi bejelentkezésekkor (webszerver vagy akár csomagszintű naplózással is).

    Természetesen ez is csak a pistike webdesign studió szintű cégeknél működik. Normális helyen az éles rendszernél a rendszer beállításait és persze magának a kódnak a változásait senki se módosíthatsz egyedül, ad-hoc módon. Ha ilyet tenne valaki, arról riasztást kap a felügyeleti részleg, és már rúgja is rá az ajtót a SWAT.
    Ezzel az olvasást nem szokás ilyen szinten naplózni, mivel az már nagyon erősen kihatna a teljesítményre is.

    Ezt nem azért alkalmazzák, mert az MD5 megbízhatatlan, sőt, ez tök független a jelszó az alkalmazásszerver oldalán történő kódolásától, tárolásától. Ez ugyanis phishing és a bejelentkezési információk a bankon kívüli naplózása vagy megszerzése ellen, valamint az ún. "replay" és "man in the middle" támadások ellen hivatott védeni,

    Igen, ezt mondják a dolgozóknak az IT vezetők. De ha össze tudsz adni kettőt meg kettőt, akkor rájössz, hogy ez a módszer ugyanolyan jól véd a belsős támadások ellen is.

    Az ugyanis aki az adatbázishoz hozzáférést tud szerezni (mert pl. admin, vagy mert exploitot tud futtatni a célgépen

    Mint mondtam: az megoldott, hogy amit módosítasz, az legális legyen (legalábbis értesüljenek róla, ha illegálisat tettél). Tudom, ez neked kicsi sci-fi, de ereszd el a fantáziádat. Innen kezdve meg csak az olvasás potenciális veszélyforrás, belsősöket tekintve.
    Mutasd a teljes hozzászólást!
  • Ha angol ABC kis és nagybetű különböző + számok vannak a jelszóban, az ha jól számolom 62 variáció 1 jegyre. 8 jegyre ez 218340105584896 variáció. Így ha 1 jelszó ellenőrzés 1 milliomod másodpercig tart - ahogy ez MD5nél kb áll - akkor bármilyen 8 karakterű jelszó törhető 218340105 sec, azaz 60650 óra alatt. Ha van 1000 gépünk, akkor ez 2.5 nap. Egy 1 millió gépes zombi hálózat esetén meg 3.6 perc.


    Megy ez sokkal hamarabb (pillanatok alatt).
    Csak egy jól irányzott szivárványtábla (rainbow table) kell hozzá, ami letölthető a netről. Ebben hash - jelszó párok vannak felsorolva (bonyolultságtól, hossztól függő) jópár GB-ban.
    Természesen a hash értékeket egy olyan adatszerkezetbe kell elhelyezni, hogy abban hatékonyan tudj keresni (valamiféle hashtable vagy talán a hashkódok 64 bites (pl. fnv) hash-e megadva, növekvő módon rendezve, hogy logaritmikusan bele tudj keresni.)
    Mutasd a teljes hozzászólást!
  • Azért érzem egy kicsit "vihar a biliben" kaliberű problémának a dolgot, mert az adatbázis szerverek eleve nehezebben törhetőek, mint akár a web/alkalmazás szerverek.

    Az, hogy az adatbázisszerver mennyire törhető, és minden további amit ezzel kapcsolatban leírtál szinte teljesen irreleváns. Azért mert hogy az ilyen jelszóadatbázisokat jellemzően nem maga az adatbáziskezelő feltörésével szerzik meg, hanem vagy az alkalmazásszerverben találnak valami olyan hibát, ami lehetővé teszi az összes jelszó (vagy jelszóhash) kilistázását a saját lekérdezései a készítő által engedélyezni nem szándékolt módon történő manipulálása révén (lásd SQL injekció és társai), vagy kódfuttatási lehetőséget szereznek a szerverre (akár az alkalmazásszerveren, akár más, az adott kiszolgálón futó szolgáltatáson keresztül), és gyakorlatilag nyers, bináris adatként férnek hozzá és töltik le az adatbáziskezelőben tárolt adatokat - köztük a jelszavakat is.

    Az első fajta támadási módszer azzal, ha magát az adatbázist - vagy legalábbis annak authentikációs tábláit - közvetlenül nem teszik olvashatóvá, hanem az authentikációt magába az adatbázisba kódolják bele (ti. tárolt eljárásokkal, amik a beléptetést és az ellenőrzést végzik, de még a hash-t sem adják ki soha, legfeljebb csak azt mondják meg egy nekik átadottról, hogy az helyes -e) megakadályozható. Ugyanakkor a második fajta támadással szemben ez sem véd.

    Továbbmegyek: a jelszavak MD5 vagy bármilyen más egy irányú kódolással való átalakítása rohadtul nem a külsősök megfékezésére szolgál, hanem arra, hogy az adminisztrátorok ne tudjanak a felhasználói adatbázissal visszaélni.

    Ez nyilván nem így van. Azért nincs így, mert a jelszó hiába van az adatbázisban szupertörhetetlen hasheléssel kódolva tárolva, az adminisztátor bármikor meg tudja oldani annak plusz naplózását akár regisztrációkor, akár a későbbi bejelentkezésekkor (webszerver vagy akár csomagszintű naplózással is). Innentől kezdve teljesen egyértelmű, hogy az adminisztátorok ellen a jelszó hashelt formábaban történő tárolása tökéletesen hatástalan, és kizárólag csakis azt a célt szolgálhatja, hogy azok számára ne legyen nyilvánvaló és könnyen megfejthető a jelszó, akiknek eleve nem is lenne szabad az authentikációs adatbázishoz hozzáférniük, de mégis sikerül nekik valahogy.

    Viszont B. lehetőségként ott van az, amit a bankok használnak (akik már régesrég nem bíznak meg az MD5-ben): az authentikációhoz kiegészítőként kell egy token, illetve az ügyfél telefonjára küldött SMSeli jelszó.

    Ezt nem azért alkalmazzák, mert az MD5 megbízhatatlan, sőt, ez tök független a jelszó az alkalmazásszerver oldalán történő kódolásától, tárolásától. Ez ugyanis phishing és a bejelentkezési információk a bankon kívüli naplózása vagy megszerzése ellen, valamint az ún. "replay" és "man in the middle" támadások ellen hivatott védeni, amire sor kerülhet anélkül is, hogy maga a bank alkalmazásszervere és az ott bármilyen formában tárolt azonosítók bármilyen módon kompromittálódnának. Ezen támadások hatásosságát és kivitelezhetőségét a bejelentkezési adatok a bank oldalán rommá hashelt formában történő tárolása nem akadályozza és nem nehezíti meg.

    Ezek megint csak olyanok, amihez belsős nehezen fér hozzá, mivel jellemzően db-ben tárolva sincsenek, csak a gép memóriájában foglalnak helyet.

    Ennek megint nem lenne semmi értelme ha így működne, hiszen a belsős támadások ellen ez nem véd. Az ugyanis aki az adatbázishoz hozzáférést tud szerezni (mert pl. admin, vagy mert exploitot tud futtatni a célgépen) jó eséllyel a gép memóriájához is ugyanúgy vagy még könnyebben hozzáférést tud szerezni. Így neki aztán tök mindegy lenne, hogy csak utóbbiban kerül tárolásra a kód. Ezért aztán ha ezek a tokenek esetleg valóban nem kerülnek kiírásra, annak egyetlen értelmes oka csakis az lehet, hogy nem érdemes tárolni őket, mert rövid időn belül úgyis lejárnak és így eleve nem érdemes őket perzisztens tárolóba kiírni.
    Mutasd a teljes hozzászólást!
  • Azért érzem egy kicsit "vihar a biliben" kaliberű problémának a dolgot, mert az adatbázis szerverek eleve nehezebben törhetőek, mint akár a web/alkalmazás szerverek. Kezdődik a probléma mondjuk ott, hogy az adatbázis szerverek kintről általában nem érhetőek el közvetlenül. Nincs ip címük, vagy ha van is akkor is csak 2 port van nyitva rajtuk, azok is ip cím szerint korlátozva:
    1. Az adatbázis kapcsolathoz szükséges port, a web/alkalmazás szerverek felé.
    2. Az adminisztrációhoz szükséges port, az cég saját ip címe felé.
    Persze mindezek megkerülhetőek - ahogy minden megkerülhető - de ha külsős behatoló lennék, biztos hogy a web/alkalmazás szervert támadnám - egyszerűen mert azt nagyságrenddel könnyebb. Továbbmegyek: a jelszavak MD5 vagy bármilyen más egy irányú kódolással való átalakítása rohadtul nem a külsősök megfékezésére szolgál, hanem arra, hogy az adminisztrátorok ne tudjanak a felhasználói adatbázissal visszaélni. Vagyis alapban feltételeznünk kell azt, hogy ismert:
    - a teljes felhasználói adatbázis
    - a szerver teljes forráskódja
    - mindenhez teljes körű hozzáférésünk van.
    Annyit azért feltételezhetünk, hogy az éles kódok módosítása naplózva történik, szóval nem tudunk észrevétlenül berakni egy trójait a login formba, belülről.

    Na innen kezdve a feladat egyszerű: kell egy egy irányú kódolás, ami ahhoz elég gyors, hogy emberi időn belül az authentikációs szerver 1 kódot ellenőrizzen, ahhoz viszont túl lassú, hogy brute force-al meg lehessen törni a minimális hosszú (biztonságú, pl értelmes szavak nem engedélyezettek) jelszót. Illetve fontos az is, hogy az algoritmus teljese optimalizált legyen - ne lehessen rajta gyorsítani. Az MD5 azért alkalmatlan jelenleg, mert túl gyors.
    Ha angol ABC kis és nagybetű különböző + számok vannak a jelszóban, az ha jól számolom 62 variáció 1 jegyre. 8 jegyre ez 218340105584896 variáció. Így ha 1 jelszó ellenőrzés 1 milliomod másodpercig tart - ahogy ez MD5nél kb áll - akkor bármilyen 8 karakterű jelszó törhető 218340105 sec, azaz 60650 óra alatt. Ha van 1000 gépünk, akkor ez 2.5 nap. Egy 1 millió gépes zombi hálózat esetén meg 3.6 perc. Ha lenne egy olyan kódolásunk, amelyből 1000-et tudna csak megcsinálni egy authentikációs szerver 1 másodperc alatt, akkor 1 jelszó törése zombi hálózattal is 2.5 nap lenne. Ha 1 másodpercig tartana 1 login, akkor 2527 napig. Más kérdés hogy ilyenkor már valószínűleg több authentikációs szervert kellene berakni, mert az általában kevés bármilyen szolgáltatásnál, hogy másodpercenként 1 felhasználót tudjunk beléptetni.

    Viszont B. lehetőségként ott van az, amit a bankok használnak (akik már régesrég nem bíznak meg az MD5-ben): az authentikációhoz kiegészítőként kell egy token, illetve az ügyfél telefonjára küldött SMSeli jelszó. Ezek megint csak olyanok, amihez belsős nehezen fér hozzá, mivel jellemzően db-ben tárolva sincsenek, csak a gép memóriájában foglalnak helyet. Szóval ahol van annyira érték a jelszó, hogy az ügyfél kifizessen egy 1-2 euros tokent/fizessen belépésenként 1-2 SMS-nyi költséget, ott ez megoldott. Ahol meg nincs, ott meg talán nem is olyan kritikus, mint amilyen színben feltüntetik.
    Mutasd a teljes hozzászólást!
  • Hihetetlen, mennyire el tudtok szállni egy témától.

    Az aranyszabály: minden adatot olyan erős védelemmel kell csak védeni, amelyik arányban van az adat értékével.

    Vagyis egy banki, hitelkártyaszám nyilvántartó stb. rendszerben, ha meglátnák egy MD5 védelmet, akkor meg lenne a véleményem a tervező szakmai tudásáról, de ha egy tömegesen szokásos (pl. blog, CMS, kisforgalmú, kis értékkel dolgozó webshop) feladatban ilyet látok, természetesen sózással és jelszóhossz minimummal, speciális karaktert tartalmazó jelszó stb. megköveteléssel, akkor az teljesen rendjén van.

    Tegyük helyre a dolgokat, a feladattal arányos legyen a hozzáállás.

    Mutasd a teljes hozzászólást!
  • "
    Ebből nem derül ki, hogy a programomban milyen védelmeket alkalmazok.
    "

    nekem a leírtak alapján az derült ki, hogy a programod különböző pontjain más-és-más hash algoritmussal ellenőrzöl, azaz van egy "belépési pont", és arra építesz, hogy ha a támadó ezen a belépési ponton bejut, mert talál egy olyan "kulcsot", amelyik az "ütközés" miatt jónak bizonyul, de valójában nem jó, az a "későbbi ponton" elbukik, mert már ott nem lesz "ütközés", emiatt nem fogja érteni, hogy mi lehet a gond, hogy akkor most mi van, miért is nem jó a talált jelszó, stb., és tovább szenved vele... persze ez is egy "jó" védelem, de mint írtam, szerintem máshol van a "leggyengébb láncszem"; persze nyilván lehet, hogy más gondolatokat takarnak a "
    Egyébként már be is integráltam az SHA224, SHA256, SHA384, SHA512-es hash-elő progit és ugyanezek HMAC-es "jelszavas" változatát. Ezzel már próbálkozhatnak egy darabig." ... "Hol írtam én olyat, hogy egymásba ágyazom a hash-eket?"
    , stb. mondataid, de nekem elsőre ez ugrott be, tudom ez nem érdekel téged, hiszen csak te tudod, hogy mit találtál ki...
    Mutasd a teljes hozzászólást!
  • Mondhatom.
    Csak egy kis tesztet és elméleti fejtegetést írtam le.
    A 660 millióba belefér az emberek által használt/használható jelszavak 99%-a az összes nyelven. ...


    kérlek, akkor mondjad, köszönöm...

    tudtommal a legtöbb beszélt nyelvben pár tízezer szó fordul elő, aminek persze napi szinten csak egy szűk részhalmaza használatos, de... ez 10**4-en nagyságrend, ha csak (tízes számrendszerbeli) 5 számjegyes suffixben gondolkodunk, akkor máris 10**9-en nagyságrenddel kell számolnunk, ez több, mint az általad megadott 6.6*10**8-on, nem? persze mondhatod azt, hogy az "ütközések" miatt nem kell ennyit próbálkozni, de te az én értelmezésem szerint magáról a jelszóról beszéltél és nem annak valamilyen hash-éről...
    meg mondhatod azt is, hogy a felhasználói "szokások" alapján sokkal kevesebb lehetőség van, de... például ismered-e azt a szokást, hogy mondjuk egy idézet, vagy bármilyen könnyen megjegyezhető mondat szavainak n. betűit használjuk kiindulásnak, pld. "Csak az a biztos, ha tele a has." -> Csaabhtah , ez nekem nem tűnik "értelmes" szónak, legalábbis magyar nyelven...


    "Természetesen feltörhetetlen program nincs. És az is igaz, hogy ott törik fel, ahol fogást találnak rajta."


    nem a programot "kell"* "feltörni", hanem a "felhasználót" (lsd. például Pszichológiai manipuláció)


    szerkesztve: értelemszerűen nem kell, sőt...
    Mutasd a teljes hozzászólást!
abcd