99.9999%-ban törhetők az SHA-1-gyel kódolt jelszavak
2017-09-05T12:56:00+02:00
2017-09-05T22:02:05+02:00
2022-07-21T11:01:56+02:00
  • Erre celoztam viszont ahogy a linken irjak az, hogy naivan osszelancolod az iteraciokat az nem egy jo megoldas az iteracio eleresere

    De, pontosan ezt is írják. Idéztem a szöveget, de máshol is ugyanezt olvashatod. Sőt, bár nyilván nem érted, de a PBKDF-2 is pontosan ezt csinálja, illetve szabványosítja.

    Persze most majd jön a magyarázat, hogy te "naivan" alatt kifejezetten egy olyan specifikus módszerre gondoltál, ami tényleg orbitális hülyeséget csinál és megkönnyíti a hash megfejtését. A baj ezzel csak az, hogy egyrészt rajtad kívül senki nem beszélt naiv módszerről; másrészt, hogy ilyen hülyeséget bármilyen algoritmus használata esetén lehet csinálni.

    Ez volt a hozzaszolasom lenyege, hogy nem jo otlet azt ajanlani, hogy "hasznalj nyugodtan SHA-512-ot csak sokszor iterald" mert ez nem egy pontos specifikacio

    Pontosan annyira (nem) pontos specifikáció, mint közölni, hogy "SHA-512 nem a legjobb otlet jelszo tarolasra. Bcrypt vagy scrypt". A másik oldalon senki nem is kért pontos specifikációt, és én sem azt akartam megmondani, hogy az SHA-512-t pontosan hogyan kell használni. Amit mondtam az volt, hogy teljesen értelmetlen általánosságban azt mondani, hogy az SHA-512-t "nem a legjobb ötlet jelszó tárolására használni". Az idézettek pedig ugyanezt mondták.

    es semmi jora nem vezet.

    Ugyanúgy, mint ahogy a "használd a bcrypt-et vagy a PBKDF2-t" sem vezet semmi jóra.

    Érteni kell, hogy mit miért és hogyan kell használni, milyen eljárás mi ellen és milyen mértékben véd, illetve mi ellen nem. Valamint, hogy alapjaiban hogyan teszi ezt. Ha valaki ezt nem teszi, akkor elkerülhetetlen sebezhetővé fogja tenni az általa készített megoldást - teljesen függetlenül attól, hogy milyen hash-algoritmust használ.
    Mutasd a teljes hozzászólást!
  • Na, most ugye aki kicsit is érti ezt a hashelés témát, az érti azt is, hogy a "collision attack" soha nem lehetetlen.

    De te magad is írod, hogy néha "lehetetlen", mert hogy például:

    A "collision attack"-ot ténylegesen csak olyan, az algoritmustól független és azon kívül eső faktorok lehetetleníthetik el, mint pl. a maximális hibás próbálkozások korlátozása. Mivel viszont ennek alapvetően semmi köze a hash-elt jelszótároláshoz, hanem a biztonsági rendszer egy attól teljesen független védelmi vonalát képezi, illetve kiszivárgott jelszóhash-ek esetében ilyen korlát nem létezik, ezért a fenti megállapítás ezek vonatkozásában teljesen értelmetlen. A lényeg, hogy az algoritmus szintjén sosincs olyan, hogy (elméleti szinten) lehetetlen a hash ütközési támadás

    Ha jól értem a linkről idézett eredeti szöveget, hogy az SHA-1 módszert csak olyan dolgokra használják lehetőleg, ahol a collision attack "lehetetlen", ott szerintem arra gondolhatnak talán, hogy mondjuk egy programban technikai okokból (mondjuk <10 elemszámú map) használod a technikát, vagy akármi más. Nyilván mivel nagyon korlátozottan és eleve nem is jelszavak tárolására használod, ezért tök nyolc az, hogy van-e bármi kriptográfiai baja az algoritmusnak. Az hogy az ilyen jellegű "problémák" osztálya vajon mekkora és mi fér bele az már egy másik kérdéskör, de nyilván van ilyen is és talán csak annyit akartak elérni, hogy tényszerűen azért az is ott legyen, hogy ilyesmire még akár jó lehet, csak hát ha jót akarsz, vagy nem vagy biztos benne, hogy veszélyes-e akkor meg inkább ne csináld...

    Persze lehet hogy félreértem.

    ui.: és a korrektség kedvéért azért nyilván hozzáteszem, hogy persze lehet és van sok olyan eset is, ahol pl. az ütközés security bajokat okoz és aki a kódot írja esetleg nem is tartja az adott részt kriptográfiailag jelentős kódrésznek... Szóval nem erre gondoltam...
    Mutasd a teljes hozzászólást!
  • Ugyanakkor persze a fenti állítás nem azt mondja, amit te mondasz, hogy ti. az ismételt használat nem eredményez nagyobb biztonságot

    Nem ezt mondtam, legyszives ne adj szavakat a szamba. En ezt allitottam:

    Ezek szerint nem igaz az, hogy az SHA fuggvenyek ismetelt hasznalata biztonsagos hash fuggvenyt eredmenyezne

    Apro kulonbseg de nem ugyanaz, amire gondoltam az az, amit mondat masodik feleben te magad is leirtal: "hanem - amúgy helyesen - azt, hogy az ismétlés _önmagában_ nem _elégséges_ feltétele a _biztonságosság_ elérésnek.
    ".
    Erre celoztam viszont ahogy a linken irjak az, hogy naivan osszelancolod az iteraciokat az nem egy jo megoldas az iteracio eleresere, ha ezt elfogadod akkor abbol ket lehetseges opcio kovetkezik:
    1. megprobalsz valami bonyolultabb modszer kitalalni ami kikeruli ezt a limitaciot = roll your own crypto
    2. hasznalsz egy standard megodlast pl bcrypt.
    Ez volt a hozzaszolasom lenyege, hogy nem jo otlet azt ajanlani, hogy "hasznalj nyugodtan SHA-512-ot csak sokszor iterald" mert ez nem egy pontos specifikacio es semmi jora nem vezet.
    Mutasd a teljes hozzászólást!
  • Ezek szerint nem igaz az, hogy az SHA fuggvenyek ismetelt hasznalata biztonsagos hash fuggvenyt eredmenyezne

    Nem ezt írják. Egyrészt az SHA-t nem is említik, illetve emelik ki (az "SHA" kifejezés nem is szerepel az általad idézett bekezdések egyikében sem), hanem az iteratív működésről általánosságban beszélnek. Ami - mint el lett mondva - pl. a bcrypt és PBKDF2 algoritmusoknak is szerves része. Tehát ha ez az állítás azt mondaná, amit te mondasz (mint ahogy nem azt teszi), akkor is általánosságban mondaná ezt az iterációkról, és akkor az SHA mellett a bcrypt-et és a PBKDF2-t is negatívan minősítené.

    Ugyanakkor persze a fenti állítás nem azt mondja, amit te mondasz, hogy ti. az ismételt használat nem eredményez nagyobb biztonságot, hanem - amúgy helyesen - azt, hogy az ismétlés _önmagában_ nem _elégséges_ feltétele a _biztonságosság_ elérésnek. Tehát hogy (kisarkítva a dolgot) pl. egy kódolást hiába ismételsz meg 1 milliószor is, ha az csak egy XOR, akkor az eredmény 1 millió iteráció után sem lesz nehezebben törhető annál, mint ha eleve csak egyszer hajtottad volna végre. Ami viszont nyilván az SHA-k esetében így már nem igaz. És ami megint csak tök más, mint amit te kihámoztál belőle.

    De ha nem lenne egyértelmű, lejjebb ezt is írják: "Notice that the final output has exactly the same amount of entropy as the first one. Iterating will not "make it more obscured". The entropy is identical. There's no magic source of unpredictability (it's a Pseudo-Random-Function, not a Random Function). There is however a gain to iterating. It makes the hashing process artificially slower. And that's why iterating can be a good idea. In fact, it's the basic principle of most modern password hashing algorithms (the fact that doing something over-and-over makes it slower). Slow is good, because it's combating the primary security threat: brute forcing. The slower we make our hashing algorithm, the harder attackers have to work to attack password hashes stolen from us. And that's a good thing!!!"

    Tehát még egyszer, csak hogy te is értsd: amit mondanak nem az, hogy az ismétlésszám nem teszi vagy legalábbis teheti nehezebbé a hash megfejtését - sőt, kifejezetten azt mondják, hogy de, pont ezt teszi. Ehelyett amit mondanak az, hogy az ismétlésszám nem vagy csak korlátosan tudja maga a kódolás eredendő gyengeségeit kompenzálni. Amilyenről viszont SHA-512 esetén jelenleg nem tudunk. Tehát SHA-512 esetében igenis "biztonságosabbá" teszi a magas iterációszám a hasht, azaz, nehezebbé, költségesebbé teszi annak visszafejtését vagy ütközés felfedezését.

    Nem de ugy latszik el kell ismetelni idonkent mert egyesek elfelejtik es azt ajanljak, hogy hasznaljuk sajat iteracios megoldasokat SHA-512 alapon a standard megoldasok helyett.

    Az iterációszám meghatározása piszkosul nem "rolling your own crypto". Ha az, akkor meg a bcrypt meg a PBKDF2 használata is az, hiszen ezen algoritmusoknak is paramétere az iterációszám (más néven költség). Amin nyilván az, hogy egyes implementációkban esetleg van egy alapértelmezés ennek vonatkozásában, semmit nem változtat.

    Szerencsere ilyet a linken nem allitanak jelszo tarolas kontextusaban

    Helyesen: a linken nem csak a jelszótárolás kontextusában állítják ezt, hanem általánosan - tehát a jelszótárolás kontextusában is.

    So I think that MD5 is still safe when a collision attack isn't possible, but should really be avoided for anything else and SHA-1 should probably be considered the same.

    Na, most ugye aki kicsit is érti ezt a hashelés témát, az érti azt is, hogy a "collision attack" soha nem lehetetlen ("isn't possible") egy hash-függvény esetében - hiszen utóbbi kimeneti (érték)halmazának mérete mindig kisebb, mint a bemeneti (érték)halmazáé, ebből adódóan pedig elkerülhetetlenül és mindig ugyanúgy (azonos bemeneti, illetve kimeneti bitszámok esetében ráadásul ugyanolyan arányban) szolgáltat ütköző értékeket. Emiatt az algoritmus szintjén nem az a kérdés, hogy a "collision attack" lehetséges -e, hanem legfeljebb az, hogy van -e a brute force-nél hatékonyabb mód rá, vagy hogy mekkora a számításigénye ezen művelet kivitelezésének.

    A "collision attack"-ot ténylegesen csak olyan, az algoritmustól független és azon kívül eső faktorok lehetetleníthetik el, mint pl. a maximális hibás próbálkozások korlátozása. Mivel viszont ennek alapvetően semmi köze a hash-elt jelszótároláshoz, hanem a biztonsági rendszer egy attól teljesen független védelmi vonalát képezi, illetve kiszivárgott jelszóhash-ek esetében ilyen korlát nem létezik, ezért a fenti megállapítás ezek vonatkozásában teljesen értelmetlen. A lényeg, hogy az algoritmus szintjén sosincs olyan, hogy (elméleti szinten) lehetetlen a hash ütközési támadás, teljesen függetlenül attól, hogy SHA-x, y, vagy z, bcrypt, vagy akármilyen másik algoritmust használunk -e.

    Nem mintha a linket nem pont arra hoztam volna példaként, hogy attól, hogy valaki bedob egy (vagy kár 10) linket, az nem jelenti 1. sem azt, hogy azok valójában az ő álláspontját igazolják, 2. sem azt, hogy amit az adott linken írnak, az tényszerű vagy helyes. Tehát nem mintha azzal, ha igazad lenne abban, hogy a linken "nem a jelszo tarolas kontextusaban" állítanak valamit, nem pont az én állításom helyességét, a nyers linkek dobálgatásának értelmetlenségét bizonyítanád.

    Csak arra kívánok rámutatni ennek megjegyzésével, hogy még ha a hivatkozott (linkelt) forrásaid tényszerűnek és hitelesnek is lennének tekinthetők (mint ahogy nem azok), neked általában akkor sem azt sikerül kihámozni az ott írtakból, ami tényleg le van írva, illetve akkor is szinte képtelen vagy logikailag helyes következtetéseket levonni az olvasottakból.
    Mutasd a teljes hozzászólást!
  •  Olvasgatást én is tudok javasolni neked - tehát ez nem érv semmi mellett vagy ellen.

    Az olvasgatas maga nem de segithet a dolgok megerteseben. Az altalad linkelt oldalon ezt irjak:

    Simple iteration is not enough

    Merely chaining hash output to input isn't sufficient for security. The iteration should take place in the context of an algorithm that preserves the entropy of the password. Luckily, there are several published algorithms that have had enough scrutiny to give confidence in their design.

    A good key derivation algorithm like PBKDF2 injects the password into each round of hashing, mitigating concerns about collisions in hash output. 

    Ezek szerint nem igaz az, hogy az SHA fuggvenyek ismetelt hasznalata biztonsagos hash fuggvenyt eredmenyezne, ennel osszetettebb megoldasra van szukseg ezert lettek a PBKDF2-hoz hasonlo fuggvenyek kidolgozva.

     Az orok aranyszabaly: "Don't roll your own crypto"
    Ez neked most új ismeret? Vagy miért tartottad fontosnak a beírását?

    Nem de ugy latszik el kell ismetelni idonkent mert egyesek elfelejtik es azt ajanljak, hogy hasznaljuk sajat iteracios megoldasokat SHA-512 alapon a standard megoldasok helyett.

    De mellesleg hozhattam volna olyan linket is, ami meg azt mondja, hogy még az MD5 is biztonságos

    Szerencsere ilyet a linken nem allitanak jelszo tarolas kontextusaban, a szoveg mas felhasznalasi modrol szol:

    There are also hashes used for various things including signatures and MACs...
    ...So I think that MD5 is still safe when a collision attack isn't possible, but should really be avoided for anything else and SHA-1 should probably be considered the same. 
    Mutasd a teljes hozzászólást!

  • Mint már korábban leírtam, ne olvasgatást javasolj, hanem érvelj! Olvasgatást én is tudok javasolni neked - tehát ez nem érv semmi mellett vagy ellen.

    + Az orok aranyszabaly: "Don't roll your own crypto"

    Ez neked most új ismeret? Vagy miért tartottad fontosnak a beírását?
    Mutasd a teljes hozzászólást!
  • Te azt allitottad, hogy a SHA-512 alkalmas biztonsagos jelszo hashelesre, a linkek mindegyiken azt irjak, hogy ne hasznalja SHA fuggvenyeket jelszo hashelesre.

    Ez nem igaz. A legtöbb linken semmi ilyent nem mondanak. Az összes általad hozott közül egyetlen egyen mondtak ilyent, amire viszont én válaszul hoztam egy másik linket, ami meg azt mondják, hogy iterációszám nélkül nincs is értelme beszélni önmagukról az algoritmusokról.

    De mellesleg hozhattam volna olyan linket is, ami meg azt mondja, hogy még az MD5 is biztonságos. Ezért is teljesen értelmetlen linkekkel megpróbálni "érvelgetni". Ha te még ezt sem érted, akkor egyszerűen nem vagy kvalifikált bármilyen racionális vita folytatására, nem csak ebben a témában.

    Mivel azokat sem olvastad volna mielott ezt az arrogans valaszt megszulod

    Most ezt képes voltál leírni "érvként" egy vitában? Ti. hogy mit tettem volna? Komolyan?

    Arról már nem is beszélek, hogy ha tényleg nem olvastam volna el, abból se következett volna sem az, hogy bármilyen állításom téves lett volna, sem az, hogy a linkelgetés random oldalakra a vitában bármit bizonyítana. Ezért az, hogy szerinted elolvastam volna -e ezt vagy azt, önmagában is teljesen irreleváns állítás.

    Persze én vagyok a hülye, hogy ilyen logikai bugyikkal leállok vitázni....
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • A linkjeid többsége az általam írtakat támasztják alá

    Te azt allitottad, hogy a SHA-512 alkalmas biztonsagos jelszo hashelesre, a linkek mindegyiken azt irjak, hogy ne hasznalja SHA fuggvenyeket jelszo hashelesre. Tudsz mutatni egy cikket az elmult nehany evbol ami ennek az ellenkezojet allitja?

    Ennyi erővel az Index meg az Origo címoldalára is linkelhettél volna, annak is akkor bizonyító/cáfoló ereje lett volna a témában.

    Mivel azokat sem olvastad volna mielott ezt az arrogans valaszt megszulod ezert igazad van nem szamitott volna.

    Csak azért, mert valami fent van az interneten, még nem lesz feltétlenül igaz. 

    Szerencsere ez igaz a te hozzaszolasaidra/cikkeidre is.
    Mutasd a teljes hozzászólást!
  • Igen, az SHA-1 és a többi is törhető. Viszont érdemes megnézni, és mind a mai napig tanulságos, hogy egy jó salt érték már nehezíti a dolgokat. Ahogy az eredeti cikkben is van:

    "There are other hashes we have not completely resolved yet ..."
    sha1(md5($salt).md5($pass)))

    Illetve még ott volt 3 variáció.

    Érdemes megnézni a táblázatot, mert vannak variációk, mint például 2x-es SHA1-es esetén már csak 45ezret tudott visszafejteni a 305 millió helyett.

    Bár én is másik hash algoritmust használok, ámbár hash-adatok képzésére mint galléria vagy kép nevek esetében pont egy sha1(md5(pass) . md5(salt:40character))-használok.
    Mutasd a teljes hozzászólást!
  • Amit leirtal annak tobb szempontbol sincs ertelme. Ha nem hinnel nekem akkor itt van egy par forras amit erdemes lenne atolvasnod:
    - Hashing security (kulonosen a FAQ elso kerdese).
    - Is using SHA-512 for storing passwords tolerable?
    - About secure password hashing (kulonosen a Speed szekcio).
    - Are salted SHA-256/512 hashes still safe if the hashes and their salts are exposed? (az itt leirtak ugyanugy igazak SHA-512-re is).
    - How to securely hash passwords

    Az SHA csalad nem jelszo hashelesre lett tervezve, ami nem jelenti azt, hogy nem alkalmas arra is.



    Ha nem értenéd mire célzok a fenti válasszal:
    - A linkjeid többsége semmiben nem mond ellent az általam írtaknak, hanem alátámasztja azokat; ami meg mégis, arra én is tudok annak ellentmondó, engem alátámasztó linket mutatni (ahogy meg is tettem). Ezért a linkelgetés random weboldalakra, fórumokra teljesen értelmetlen, főleg, ha ki sem tudod emelni belőlük, hogy azok milyen ponton támasztanak alá vagy mondanak ellent valamelyik itt elhangzott állításnak. Ennyi erővel az Index meg az Origo címoldalára is linkelhettél volna, annak is akkor bizonyító/cáfoló ereje lett volna a témában.
    - Csak azért, mert valami fent van az interneten, még nem lesz feltétlenül igaz. Sőt, legtöbbször nem az.
    Mutasd a teljes hozzászólást!
  • Mivel tudom, hogy ugyis ragaszkodni fogsz az igazadhoz, elorebocsatom, hogy nem fogok leallni vitatkozni a lentebb leirtakrol.

    Ha magad is tudod előre, hogy nem tudod megvédeni az állításaid igazát, akkor miért állsz le egyáltalán vitatkozni a témáról?

    Az SHA-1 ellen bemutatott tores a collision resistancejet tori meg, mig a jelszavak hashelesehez csak a preimage attack ellen kell vedekezni, ami tovabbra sincs megtorve.

    Mivel a hashelt jelszótárolás esetén a jelszó ellenőrzése a hash-ek, nem a jelszavak összehasonlításán alapul, ezért ahhoz, hogy az adott rendszerbe be tudjál lépni, nem kell feltétlenül az eredeti jelszót tudnod, hanem éppen elég ha tudsz egy olyan jelszót, amiből ugyanaz a hash képződik.

    Emiatt ebből a szempontból a megkülönböztetésed teljesen értelmetlen, hiszen mindegy, hogy ütközést könnyű -e generálni, vagy az eredeti (hashelt) bemenetet valamilyen módon visszafejteni, mert az eredmény ugyanaz. Így is, úgy is meg lehet majd állapítani egy jelszót a hash alapján, amivel be lehet majd lépni az adott rendszerbe.

    Az egyetlen különbség a kettő között legfeljebb csak a visszafejtett jelszó más rendszerekben történő felhasználása szempontjából van, feltéve, hogy ugye azokban újrafelhasználásra került, ileltve hogy a másik rendszer eltérő sózást használ. Ha nem, akkor ez is tök mindegy, és ebből a szempontból is gyakorlatilag semmi különbség nincs a kétfajta gyengeség között.

    Tehat jelszavak SHA1 hashelesehez a korabbi toresnek semmi koze.

    Lásd fent!

    Masodik: az SHA1, SHA512, stb. fuggvenyeknek nincs iteracio szama

    Kösz, hogy megerősítetted azt, amit leírtam.

    akarmit is ertettel alatta.

    Hadd segítsek: Ciklus (programozás) – Wikipédia

    Harmadik: "SHA512 sokkal biztonsagosabb es megfelelo jelszavak hashelesere":

    Ez az idézet kitől származik?

    Ezert vannak az ujabb bcrypt, scrypt, argon2, stb jelszo hashelo fuggvenyek, amik probalnak a celhardveres, GPU-s es egyeb toresek ellen is vedekezni (pl. tobb memoria hasznalataval, alapbol tobbszalu mukodessel, stb).

    Ez legfeljebb akkor számít, ha egyetlen konkrét hash-t, jelszót, akármit akar megfejteni az ember. Ha nem, akkor teljesen mindegy, hogy mennyire párhuzamosítható a "törés", és végső soron csak az fog számítani, hogy hány lépés szükséges akár a brute force, akár egyéb jellegű megfejtéshez. Az meg pl. az említett iterációszámtól is erősen függ, és emiatt lehetetlenné teszi utóbbi nélkül bármiféle univerzális reláció felállítását a különböző hash-függvények között.


    Mindezek ellenére és végén még mindig nem értem miért született meg a hozzászólásod, miért nekem címezted, és mit akartál volna egyáltalán mondani vele? Azért kérdezem, mert az állításaid közül még azoknak, amik helyesek is, semmi relevanciája nincs sem a cikkben szereplőkkel, sem az általam leírtakkal.
    Mutasd a teljes hozzászólást!
  • Amit leirtal annak tobb szempontbol sincs ertelme(lasd Kate hozzaszolasat). Ha egyikunk sem hinnel akkor itt van egy par forras amit erdemes lenne atolvasnod:

     - Hashing security (kulonosen a FAQ elso kerdese).

     - Is using SHA-512 for storing passwords tolerable? 

     - About secure password hashing (kulonosen a Speed szekcio).

     - Is SHA-256 + Salt still safe for password storage? (az itt leirtak ugyanugy igazak SHA-512-re is).
     
     - How to securely hash passwords

    Az SHA csalad egyszeruen nem jelszo hashelesre lett tervezve => nem kene jelszo hashelesre hasznalni. Viszonylag egyszeru a helyzet.
    Mutasd a teljes hozzászólást!
  • > Teljesen jó ötlet.

    Ne haragudj Sting de itt alapveto felreertesekrol van szo. Mivel tudom, hogy ugyis ragaszkodni fogsz az igazadhoz, elorebocsatom, hogy nem fogok leallni vitatkozni a lentebb leirtakrol. Remelem a tobbiek akik olvassak a kommentem maguktol utananeznek es belatjak, hogy nem alaptalanul irom.

    Kezdjuk az elso felreertest, a hash fuggvenyeknek legalabb ketfele tulajdonsagarol beszelhetunk:
    - collision resistance
    - preimage attack resistance

    Az SHA-1 ellen bemutatott tores a collision resistancejet tori meg, mig a jelszavak hashelesehez csak a preimage attack ellen kell vedekezni, ami tovabbra sincs megtorve. Tehat jelszavak SHA1 hashelesehez a korabbi toresnek semmi koze.

    Masodik: az SHA1, SHA512, stb. fuggvenyeknek nincs iteracio szama, akarmit is ertettel alatta.

    Harmadik: "SHA512 sokkal biztonsagosabb es megfelelo jelszavak hashelesere": egy viszonylag uj HashCat benchmark alapjan egy SHA512 hasht 8x lassabb megtorni, mint egy SHA1-et. Tehat ennyivel tobb idobe vagy penzbe kerul egy tamadonak megtorni. Egy nagysagrend.

    Egy PBKDF2-t 100000-es iteracioszammal korulbelul 100000x tobb ido / penz. Ami mar 5 nagysagrend. (Nem mindegy, hogy 1 nap vagy 100000 nap feltorni.)

    De persze PBKDF2 meg mindig konnyebben torhetoek celhardverrel (pl. FPGA). Ezert vannak az ujabb bcrypt, scrypt, argon2, stb jelszo hashelo fuggvenyek, amik probalnak a celhardveres, GPU-s es egyeb toresek ellen is vedekezni (pl. tobb memoria hasznalataval, alapbol tobbszalu mukodessel, stb).
    Mutasd a teljes hozzászólást!
  • SHA-512 nem a legjobb otlet jelszo tarolasra

    Teljesen jó ötlet. Az egyetlen ellenjavallat az alacsony iterációszám, ami viszont bármilyen más hash-függvény esetében is probléma. A különbség csak annyi, hogy a kifejezetten jelszókódolásra kidolgozott hash-eknél alapértelmezett a magas iterációszám, míg az SHA-knál sokszor opcionális. Cserébe bizonyos processzor-architektúrákon sokkal hatékonyabban (gyorsabban) hajthatók végre, mint más, alternatív hash-függvények.
    Mutasd a teljes hozzászólást!
  • SHA-512 nem a legjobb otlet jelszo tarolasra. Bcrypt vagy scrypt(esetleg PBKDF2 de az nem igazan hash-elesre valo).
    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