MD5 en SHA-1 gekraakt - en nu?

[JayVee]

_{Ik heb lang zitten denken waar ik dit topic nou moet plaatsen, mag het hier?}

Gisteren las ik op slashdot over een artikel waarin geclaimd wordt dat zowel SHA-1 en MD5 gekraakt zijn. Aangezien deze twee hash algoritmen erg veel gebruikt worden op internet is dit best wel belangrijk nieuws. In het artikel gaan ze niet in op hoe "ver" de hashe methoden gekraakt zijn, dus hoe makkelijk het nu is om een hash collision te vinden.

MD5 is praktisch de standaard als het gaat om het hashen van wachtwoorden bij web applicaties, en SHA-1 wordt o.a. gebruikt voor SSL en internet banking (Rabobank internet kassa bijvoorbeeld).

Dus, hoe moeten we nu verder? Welke hash algorithmen moeten we nu gebruiken? En hoe snel denken jullie over te gaan naar alternatieven? Is het al nodig om oude code te updaten of kun je gewoon alleen bij toekomstige applicaties betere algoritmen te gebruiken? Persoonlijk denk ik dat het laatste beter is, er is nog geen reden voor paniek. Zelfs de grote jongens gebruiken deze aanpak:

In early 2005, Wang and her research team announced that they had succeeded in cracking SHA-1. In addition to the U.S. government, well known companies like Microsoft, Sun, Atmel, and others have also announced that they will no longer be using SHA-1.

[XWB]

Gewoon verder blijven gebruiken? Als je de hash sleutel hebt kan je "makkelijk" opzoek gaan naar een woord dat dezelfde hash sleutel oplevert. Dus als je nou even zorgt dat niemand in je db kan heeft ook niemand die sleutels.

[Onbekend]

In het artikel staat dat het vrij lang duurt voordat de informatie achterhaald is. Ik zal nog steeds md5 gebruiken.

Immers uiteindelijk zal alles gekraakt kunnen worden. Het is alleen een kwestie van tijd.

[Gomez12]

Best leuk dat de basisprincipes gekraakt zijn. Maar de basis principes van bijv md5 waren altijd al goed te kraken door rainbow tables.

Gooi er een goede salt bij en het is alweer een heel ander kraak spelletje.

Hacku schreef op zondag 21 januari 2007 @ 11:35:
Gewoon verder blijven gebruiken? Als je de hash sleutel hebt kan je "makkelijk" opzoek gaan naar een woord dat dezelfde hash sleutel oplevert. Dus als je nou even zorgt dat niemand in je db kan heeft ook niemand die sleutels.

Hash-sleutel kan theoretisch gesniffed worden, je dbase kan gekraakt worden. 100% garantie hiertegen is niet zo maar even te geven.

Alhoewel het natuurlijk wel de vraag is hoeveel is je data waard. Een forum is nog steeds superveilig met salted md5's. ( zelfs met gewone md5's vind ik het in de meeste gevallen nog redelijk betrouwbaar ) Een bankapplicatie moet hogere veiligheidseisen stellen.

Maar simpel gesteld als het kraken van een wachtwoord op 1 enkele computer langer duurt dan 1 week dan vind ik het voor de meeste toepassingen die ik heb betrouwbaar.

[Verwijderd]

Laten we het ze ook niet te makkelijk maken:

$hash = sha1($pepper . (md5($salt . $password));

Met een random gekozen $salt, $pepper en $password is het niet ontzettend makkelijk om het wachtwoord dan te achterhalen.

[Gerco]

maartenvb: Dat lijkt veilig, maar is imo minder veilig dan je denkt

Je doet namelijk eerst md5() op een dataset > 128 bits en dan doe je nog eens sha-1() over de 128 bits van de md5 hash alleen. Die sha-1 heeft dus lang niet de "kracht" van een losse sha-1(). Zoiets is misschien beter:

code:

hash1 = md5(salt, passphrase)
hash2 = sha1(pepper, passphrase)

store_in_db(userid, hash1, hash2)

Als men nu een collision vind voor de ene hash, heb je nog niets, want je moet om dit succesvol te kraken 1 string vinden die voor zowel sha1 als md5 een collision is.

[Verwijderd]

"md5 en/of sha1 zijn gekraakt" is totaal misleidend.
Er is helemaal niets gekraakt.
Wat er wel is gebeurt, is dat er een zeer kleine "zwakheid" in het algoritme is gevonden, waardoor het in theorie mogelijk zou zijn om opzettelijk collisions te veroorzaken.
Dus je kan MD5 en SHA1 makkelijk blijven gebruiken hoor.
Meer info hier:
http://en.wikipedia.org/wiki/Hash_collision
http://www.cits.rub.de/MD5Collisions/
http://www.cryptography.com/cnews/hash.html

[Soultaker]

Het is Slashdot, hè! Het artikel dat ze gisteren postten was een verhaspeling van een bericht van twee jaar geleden, en staat bol van de onzin, zoals dat MD5 een subset van SHA-1 zou zijn, verwisselt hashfuncties en encryptie (waarvoor de overheid AES gebruikt). Kortom: het is een storm in een glas water, en oud nieuws.

[XWB]

Klopt, het heeft ook op de frontpage gestaan: nieuws: SHA-0 niet 100% veilig, ook MD5 en SHA-1 wellicht zwak

[Verwijderd]

MD5 is best simpel te cracken, zo heb je bijvoorbeeld John the Ripper. Eigenlijk zouden ze een nieuwe codering moeten verzinnen.

[Verwijderd]

Verwijderd schreef op zondag 21 januari 2007 @ 14:04:
MD5 is best simpel te cracken, zo heb je bijvoorbeeld John the Ripper. Eigenlijk zouden ze een nieuwe codering moeten verzinnen.

Dan snap jij niet wat hash algoritmes precies doen.
MD5 is niet te "cracken", het is een one-way algoritme.
Wat John the ripper doet is brute force alle paswoorden uitproberen (met dictionary bijvoorbeeld) en kijken of er toevallig eentje klopt (met een gelijke uitkomst van de hash functie).
Deze aanpak werkt altijd, met eender welke beveiliging.

[ Voor 4% gewijzigd door Verwijderd op 21-01-2007 15:10 ]

[eghie]

Ga voor safe en ga voor het Whirlpool hash algoritme. Deze is aardig groot en heeft genoeg implementaties in verschillende programmeertalen. Dus het is ook nog makkelijk te gebruiken. Hier kun je wel weer een tijdje mee vooruit in ieder geval.

Zie ook deze site: http://paginas.terra.com....aulobarreto/hflounge.html

Natuurlijk dit in combinatie met een salt.

In PHP kun je het bijvoorbeeld zo oplossen:

PHP:

$salt = "meuk";
$password = hash('whirlpool', hash('ripemd128', hash('tiger128,4', $salt) . $plaintext));

[ Voor 35% gewijzigd door eghie op 21-01-2007 18:11 ]

[Verwijderd]

Aanvulling op Gomez2 en enkyrpt:
Stel je gebruikt een forum dat wachtwoorden opslaat als md5 hash. Dan is het nu dus mogelijk om een wachtwoord te vinden dat wordt geaccepteerd.
Stel je doet een hash met een salt. Dan moet de collision met dezelfde salt beginnen of eindigen, en is het risico al een stuk kleiner.
Maar in de eerste plaats: hoe komt die persoon aan de hash? Er is ergens anders in het systeem al een beveiligingslek. En dan nog doet md5 precies wat het moet doen: het originele wachtwoord "beschermen". Het voegt niets toe aan de beveiliging van de applicatie!

[JayVee]

Hacku schreef op zondag 21 januari 2007 @ 11:35:
Gewoon verder blijven gebruiken? Als je de hash sleutel hebt kan je "makkelijk" opzoek gaan naar een woord dat dezelfde hash sleutel oplevert. Dus als je nou even zorgt dat niemand in je db kan heeft ook niemand die sleutels.

Zo simpel is het niet. SHA-1 wordt bijvoorbeeld bij Rabobank internet kassa als signature gebruikt. Als het nu echt makkelijk is geworden om een hash collision te maken zou je eventueel betaalgegevens kunnen wijzigen!
_{Voorbeeld: Op je eigen website heb je dan een formulier waar in staat hoe veel je klant moet gaan betalen. Dit formulier wordt gepost naar de Rabobank. Om ervoor te zorgen dat de klant niet zomaar gegevens kan wijzigen (prijs, valuta, order nr, etc) post je ook een signature van die data plus een wachtwoord (shared secret) naar de Rabobank.}

Soultaker schreef op zondag 21 januari 2007 @ 13:01:
Het is Slashdot, hè! Het artikel dat ze gisteren postten was een verhaspeling van een bericht van twee jaar geleden, en staat bol van de onzin, zoals dat MD5 een subset van SHA-1 zou zijn, verwisselt hashfuncties en encryptie (waarvoor de overheid AES gebruikt). Kortom: het is een storm in een glas water, en oud nieuws.

Ik had nog op tweakers.net gezocht naar nieuws omdat ik meende dat een jaar geleden al een shortcut was gevonden om collisions voor een md5 hash te krijgen. Ik kan mij haast niet voorstellen dat ze dit twee jaar laten "opnieuw" posten, maar ik vond het wel raar dat er niet werd gelinkt naar een (wetenschappelijk) paper en niet werd ingegaan op de details (hoe goed is de shortcut, etc).

Al in al dus blijkbaar lang niet zo bijzonder dan je zou denken als je het artikel leest.

[ Voor 33% gewijzigd door JayVee op 21-01-2007 18:04 . Reden: Eerste reactie toegevoegd ]

[PolarBear]

JayVee schreef op zondag 21 januari 2007 @ 17:55:
[...]
Zo simpel is het niet. SHA-1 wordt bijvoorbeeld bij Rabobank internet kassa als signature gebruikt. Als het nu echt makkelijk is geworden om een hash collision te maken zou je eventueel betaalgegevens kunnen wijzigen!
_{Voorbeeld: Op je eigen website heb je dan een formulier waar in staat hoe veel je klant moet gaan betalen. Dit formulier wordt gepost naar de Rabobank. Om ervoor te zorgen dat de klant niet zomaar gegevens kan wijzigen (prijs, valuta, order nr, etc) post je ook een signature van die data plus een wachtwoord (shared secret) naar de Rabobank.}

Dan gebruik je toch en een SHA1 hash en een MD5 hash als signature? Het zijn twee verschillende hashmethodes (hoewel ze wel van de principes uitgaan).

[PommeFritz]

Als je er wakker van ligt waarom gebruik je dan niet gewoon SHA-256 of SHA-512.

[Verwijderd]

Verwijderd schreef op zondag 21 januari 2007 @ 17:13:
Stel je gebruikt een forum dat wachtwoorden opslaat als md5 hash. Dan is het nu dus mogelijk om een wachtwoord te vinden dat wordt geaccepteerd.

Onzin.
Als jullie nu gewoon even de moeite doen van de links te geven die ik helemaal in de het begin al gaf,
zou dit topic niet zo vol zitten met misverstanden.
Dus nogmaals, LEES DIT ALVORENS TE REAGEREN:
http://en.wikipedia.org/wiki/Hash_collision
http://www.cits.rub.de/MD5Collisions/
http://www.cryptography.com/cnews/hash.html

Anders krijgen we hier nog tientallen mensen die beweren dat er nu MD5 en SHA-1 paswoorden gekraakt zullen worden

[ Voor 46% gewijzigd door Verwijderd op 21-01-2007 19:40 ]

[Verwijderd]

Ook onbekend schreef op zondag 21 januari 2007 @ 11:36:

Immers uiteindelijk zal alles gekraakt kunnen worden. Het is alleen een kwestie van tijd.

er is toch een algoritme waarvan wiskundig is bewezen dat het onkraakbaar is?

[XWB]

@enkrypt, relax Volgens mij bedoeld Cheatah gewoon de brute force manier, maar een degelijk forum pakket is daartegen beveiligd (bv na 3 mislukte pogingen niet meer kunnen inloggen).

[ Voor 3% gewijzigd door XWB op 21-01-2007 19:45 ]

[Verwijderd]

Verwijderd schreef op zondag 21 januari 2007 @ 19:43:
[...]

er is toch een algoritme waarvan wiskundig is bewezen dat het onkraakbaar is?

Nee.

HackU : nee, want dat heeft er helemaal niets mee te maken. Brute forcen is mogelijk met ELK hash algoritme, van nu of de toekomst. Dat heeft niks te maken met de recent ontdekte zwaheid.

[Verwijderd]

Verwijderd schreef op zondag 21 januari 2007 @ 19:34:

Onzin.

Volgens mij lees je niet goed. Dat er een wachtwoord gevonden kan worden dat geaccepteerd wordt (lees: dezelfde hash oplevert) is juist waar het om draait. Ik beweer nergens dat dat hetzelfde wachtwoord is dat de gebruiker invoert bij authenticatie.

Juist die originele wachtwoorden moeten nog veilig zijn, en dat is eigenlijk de enige reden om die hash überhaupt te gebruiken. De originele wachtwoorden zijn alleen niet veilig als ze "simpel" te bruteforcen zijn met een dictionary attack of verwante werkwijzen. Sterke wachtwoorden zijn gewoon veilig met een MD5 of SHA1 hash.

[PolarBear]

Verwijderd schreef op zondag 21 januari 2007 @ 19:34:
[...]

Anders krijgen we hier nog tientallen mensen die beweren dat er nu MD5 en SHA-1 paswoorden gekraakt zullen worden

Laat ik het zo zeggen stel dat in een database een hash is opgeslagen van je wachtwoord. En stel je wachtwoord is "123456". Stel dat er een collision is met "abcdef". Dan is misschien je wachtwoord niet gekraakt (als in achterhaald) maar als de website alleen een hash controleerd ben je wel de lul.

[Onbekend]

Ik schreef eerder dit:

Ook onbekend schreef op zondag 21 januari 2007 @ 11:36:
Immers uiteindelijk zal alles gekraakt kunnen worden. Het is alleen een kwestie van tijd.

Ik bedoel dus hiermee dat een bericht altijd gedecodeerd kan worden indien de ontvanger dat ook kan.
Maar als men (nog) niet over de juiste decryptietechniek/sleutel beschikt kan dat dus nog enige tijd duren.

[SH4D3H]

PolarBear schreef op zondag 21 januari 2007 @ 19:50:
[...]
Laat ik het zo zeggen stel dat in een database een hash is opgeslagen van je wachtwoord. En stel je wachtwoord is "123456". Stel dat er een collision is met "abcdef". Dan is misschien je wachtwoord niet gekraakt (als in achterhaald) maar als de website alleen een hash controleerd ben je wel de lul.

Zou het gebruik van beide hashes tesamen zoiets niet op kunnen lossen.
Je wilt natuurlijk niet het echte wachtwoord in de database, maar je zou wel de MD5 én SHA-1 op kunnen slaan van het origineel.

Ik neem aan dat als wachtwoord '123456' en collision heeft met 'abcdef' bij MD5 dat niet ook bij SHA-1 zo is, of denk ik dan verkeerd?

[eghie]

Ook onbekend schreef op zondag 21 januari 2007 @ 19:51:
Ik schreef eerder dit:

[...]

Ik bedoel dus hiermee dat een bericht altijd gedecodeerd kan worden indien de ontvanger dat ook kan.
Maar als men (nog) niet over de juiste decryptietechniek/sleutel beschikt kan dat dus nog enige tijd duren.

We hebben het hier over One-way Hash algoritmen, geen encryptie technieken. Hier zit namelijk een verschil tussen. One-way hashes kunnen niet gedecrypt worden, alleen geencrypt (om het op die terminologie te houden). Die kun je dus niet terug halen naar het oorspronkelijk wachtwoord. Ik weet niet of je goed bent in wiskunde, maar vergelijk het eens met de volgende 2 berekeningen:

code:

7%2=1 en 13%2=1 (% == mod)

Deze berekening houd eigenlijk in, wat je overhoud na volledige delingen. (7/2 = 3 waarbij je 1 overhoud). Dit is ook een eenmalige berekening waarvan uit het eindgetal niet af te leiden is wat er voor die % stond. Zo heb je dat ook met one-way hashes. Omdat de ontvanger het ook niet kan decrypten, zet de ontvanger de hash gewoon als hash in de database en vergelijkt hij ze gewoon als iemand een wachtwoord invoert. Want van dezelfde tekst komt altijd wel dezelfde hash. Daarom kan hij gewoon het volgende doen:

code:

if (hashed_password == hashed_password_database)
{
    user.loggedIn = true;
}

SH4D3H schreef op zondag 21 januari 2007 @ 19:56:
[...]

Zou het gebruik van beide hashes tesamen zoiets niet op kunnen lossen.
Je wilt natuurlijk niet het echte wachtwoord in de database, maar je zou wel de MD5 én SHA-1 op kunnen slaan van het origineel.

Ik neem aan dat als wachtwoord '123456' en collision heeft met 'abcdef' bij MD5 dat niet ook bij SHA-1 zo is, of denk ik dan verkeerd?

Dit zou werken bij collision, echter maakt het wel makkelijker met Rainbow tables doorzoeken naar het juiste wachtwoord, je hebt namelijk 2 keuzes. En MD5 wordt nu al zo lang gebruikt binnen Rainbow tables, dat ze inmiddels al wel een hele reeks doorzoekbaar hebben liggen.

Ook vanwege die Rainbow tables raad ik trouwens Whirlpool als hash algoritme aan. Een algoritme die nog niet is opgenomen in de meeste Rainbow tables. Als hij er wel in wordt opgenomen neemt dat machtig veel ruimte in beslag. En voor dit algoritme zijn nog geen collisions gedetecteerd. En ook zijn er nog geen shortcut aanvallen bekend om de hash sneller te bruteforcen.

[ Voor 29% gewijzigd door eghie op 21-01-2007 20:15 ]

[brokenp]

Ik denk dat de hele discussie hier niet de goede kant op gaat. Er wordt hier vooral gekeken naar het hashen van passwords e.d. echter het gevaar ligt imo bij digitale handtekeningen, en daarbij behorend dus de sterkte van het hele certifcaten systeem zoals tegenwoordig gebruikt.

Er zijn al diverse realistische X5.09 certificaten geconstrueerd met identieke hash values.

[eghie]

brokenp schreef op zondag 21 januari 2007 @ 20:15:
Ik denk dat de hele discussie hier niet de goede kant op gaat. Er wordt hier vooral gekeken naar het hashen van passwords e.d. echter het gevaar ligt imo bij digitale handtekeningen, en daarbij behorend dus de sterkte van het hele certifcaten systeem zoals tegenwoordig gebruikt.

Er zijn al diverse realistische X5.09 certificaten geconstrueerd met identieke hash values.

Inderdaad, certificaten genereren met hashes om te gebruiken als validaties op het certificaat kan ook nog een risico hiermee zijn. Dus er zijn al werkende certificaten gegenereerd met identieke hash? Kun je hier toevallig ook een bron van vinden? Lijkt me wel interessant.

Wat ze moeten doen om collision tegen te gaan met certificaten is een wat uitgebreidere hash algoritme nemen, maar ook niet alleen de data in het certificaat hashen, maar ook de structuur van het certificaat zelf. Die dus als een soort van salt gebruiken. Scheelt al een hoop met valide collisions.

[flowerp]

SH4D3H schreef op zondag 21 januari 2007 @ 19:56:
[...]

Zou het gebruik van beide hashes tesamen zoiets niet op kunnen lossen.
Je wilt natuurlijk niet het echte wachtwoord in de database, maar je zou wel de MD5 én SHA-1 op kunnen slaan van het origineel.

Ik neem aan dat als wachtwoord '123456' en collision heeft met 'abcdef' bij MD5 dat niet ook bij SHA-1 zo is, of denk ik dan verkeerd?

Als je wachtwoord zo zwak is, dat er niet alleen -een- collision gevonden wordt bij een reverse lookup van de hash, maar ook meteen het echte password, dan helpt dat ook niet veel. Daarnaast, als iemand zowel een MD5 als SHA-1 rainbow database heeft, dan vergroot het zelfs de kans om het echte wachtwoord te achterhalen. Dit echte wachtwoord kan dan weer gebruikt worden op andere plekken, waar een willekeurige collision niet werkt (omdat men b.v. op die andere plek een andere hash gebruikt).

[brokenp]

eghie schreef op zondag 21 januari 2007 @ 20:22:
[...]

Inderdaad, certificaten genereren met hashes om te gebruiken als validaties op het certificaat kan ook nog een risico hiermee zijn. Dus er zijn al werkende certificaten gegenereerd met identieke hash? Kun je hier toevallig ook een bron van vinden? Lijkt me wel interessant.

zie
http://www.win.tue.nl/hashclash/TargetCollidingCertificates/ (md5 based certificates)
http://www.iaik.tugraz.at/research/krypto/collision/ (sha-1)

Wat ze moeten doen om collision tegen te gaan met certificaten is een wat uitgebreidere hash algoritme nemen, maar ook niet alleen de data in het certificaat hashen, maar ook de structuur van het certificaat zelf. Die dus als een soort van salt gebruiken. Scheelt al een hoop met valide collisions.

Maakt denk ik niet zo veel uit, lees maar even de links

[SH4D3H]

eghie schreef op zondag 21 januari 2007 @ 20:08:
je hebt namelijk 2 keuzes.

Mja, stom, idd.
Als je bij beide algoritmes eenzelfde wachtwoord eruit krijgt, zal dat vast het origineel wel zijn.
En aangezien mensen zoiets vaak hergebruiken is dat misschien wel gevaarlijker dan slechts 1 algoritme te gebruiken.


Edit: Toch eh, zolang jouw applicatie veilig is, is het wel een goed idee.
Stel hacker X krijgt via een slecht beveiligde applicatie 1 hash en zoekt daarvoor een collision.
Daarna probeert X op jouw applicatie in te loggen met die collision (bijv. omdat de gebruiker in een profiel had dat ie ook een account heeft op jouw applicatie) maar dat gaat dan niet.
Als je zorgt dat er niemand bij de hashen kan komen, kun je je gebruikers wel een extra zekerheid bieden.

Of zit ik er weer naast?

[ Voor 40% gewijzigd door SH4D3H op 21-01-2007 20:41 ]

[JeRa]

@SH4D3H

Ik denk dat het in dat geval veel gemakkelijker is om met random salts te werken, op die manier weet je vrij zeker dat collisions op andere sites niet voor jouw applicatie zullen werken. Ik gebruik bijvoorbeeld de crypt()-functie in PostgreSQL (dmv de pgcrypto contrib module):

crypt(wachtwoord, gen_salt('bf'))

De 'bf' staat voor Blowfish, het hashing algoritme dat wordt gebruikt.

[flowerp]

SH4D3H schreef op zondag 21 januari 2007 @ 20:33:
Of zit ik er weer naast?

Mischien niet, maar als de hacker dan gewoon zelf een site beheert waarbij hij (zij? ) usernames aan passwords koppelt, en de gebruiker gebruikt dezelfde username/password combi op diverse andere systemen, dan ben je alsnog het bokje.

Daarnaast hoef je nog niet eens 2 verschillende hashes op te slaan. Als je er vanuit gaat dat jouw DB safe is, en je wilt alleen attacks voorkomen d.m.v. collisions die geprobeerd worden, dan zou je ook in code iets specificieks met het wachtwoord kunnen doen, bv om en om bepaalde karakters erin weven. Bv, "test" wordt dan "t#e@s*!t" oid. Als alleen je DB het zwakke punt is, en niet je sourcecode dan zou dat ook tegen rainbow lookups kunnen helpen.

Of zit ik er ook naast?

1 ding wat ik wel geleerd hebt is dat denken dat je met je boeren-verstand slim bent niet altijd slim is. Cryptography is een zeer complex gebied, en als het er echt om gaat zou ik liever OF iemand inhuren die hier echt een expert is, OF zelf eens stevig gaan studeren hierop. En met stevig studeren bedoel ik niet even een google query doen en een of andere how-to vluchtig doorlezen.

[Rukapul]

PolarBear schreef op zondag 21 januari 2007 @ 19:50:
[...]


Laat ik het zo zeggen stel dat in een database een hash is opgeslagen van je wachtwoord. En stel je wachtwoord is "123456". Stel dat er een collision is met "abcdef". Dan is misschien je wachtwoord niet gekraakt (als in achterhaald) maar als de website alleen een hash controleerd ben je wel de lul.

Die collision is er gegarandeerd. Immers een oneindige hoeveelheid inputs mapt op een beperkt aantal outputs met een hash algoritme.

De gepubliceerde aanval gaat erom dat er een methode is gevonden om collisions te vinden op een manier die efficienter is dan brute force. Echter dat maakt voor jouw toepassing niets uit want de aanval heeft alleen zin als men de originele input heeft (het wachtwoord) wat niet het geval is. Sterker nog, een aanvaller weet helemaal niets.

De gepubliceerde aanval verandert niets aan het vinden van een input bij een gegeven output (one way) en maakt het bijvoorbeeld ook niet efficienter om een database met gehashte wachtwoorden aan te vallen en zodoende geldige inputs te verkrijgen (wat collisions met het echte wachtwoord zouden zijn).

eghie schreef op zondag 21 januari 2007 @ 20:22:
Wat ze moeten doen om collision tegen te gaan met certificaten is een wat uitgebreidere hash algoritme nemen, maar ook niet alleen de data in het certificaat hashen, maar ook de structuur van het certificaat zelf. Die dus als een soort van salt gebruiken. Scheelt al een hoop met valide collisions.

Weet je eigenlijk wel waar je over praat? Het klinkt als toveren met cryptotermen.

Als we als voorbeeld een X.509 certificaat nemen dan zal de structuur middels een ASN.1 structuur vastliggen en ge-encode worden op een bepaalde wijze (bv. DER of BER). Hierover wordt een cryptographische hash berekend, welke encrypt wordt met de private key volgens een asymmetrisch algoritme zoals RSA. De structuur van het certificaat is dus expliciet meegenomen in de handtekening.

De use case met certificaten is bv de volgende: iemand vraagt je iets te tekenen, jij tekent, de ander heeft van tevoren een collision bepaald, en zet jou handtekening onder die andere boodschap.

[ Voor 30% gewijzigd door Rukapul op 21-01-2007 21:17 ]

[SH4D3H]

flowerp schreef op zondag 21 januari 2007 @ 20:51:
[...]
Mischien niet, maar als de hacker dan gewoon zelf een site beheert waarbij hij (zij? ) usernames aan passwords koppelt, en de gebruiker gebruikt dezelfde username/password combi op diverse andere systemen, dan ben je alsnog het bokje.

Ook nog, ja

Daarnaast hoef je nog niet eens 2 verschillende hashes op te slaan. Als je er vanuit gaat dat jouw DB safe is, en je wilt alleen attacks voorkomen d.m.v. collisions die geprobeerd worden, dan zou je ook in code iets specificieks met het wachtwoord kunnen doen, bv om en om bepaalde karakters erin weven. Bv, "test" wordt dan "t#e@s*!t" oid. Als alleen je DB het zwakke punt is, en niet je sourcecode dan zou dat ook tegen rainbow lookups kunnen helpen.

Als je systeem werkt dmv CHAP, zodat je dus nooit een password verstuurd, zou je, indien het gaat om bijvoorbeeld een website, daar niets aan hebben.
Als jij in je Javascript, die vrij te bekijken is, zet: md5( 'string' + password ) dan schiet het ook niets op.
Als het password wel verstuurd wordt is dat natuurlijk wel een optie.

[Cartman!]

Voor de PHP-ers onder ons: http://nl2.php.net/mhash

De mhash library bevat inmiddels alle boven besproken hashmethodes. De 1e reactie in de manual heb ik geschreven om zo makkelijk te upgraden om in je hele site over te stappen naar n nieuwe hash methode (dit stel je dan bijv. in als je begint met de ontwikkeling van je site).
Zoals eerder al gezegd was : salten blijft belangrijk

[Verwijderd]

Is het als je dit allemaal zo bekijkt niet veiliger om je eigen encryptie algoritme te schrijven? En dan niet de broncode vrijgeven? Of denk ik nu gewoon veel te simpel?

[Gerco]

Verwijderd schreef op zondag 21 januari 2007 @ 22:06:
Of denk ik nu gewoon veel te simpel?

Ja: Security by obscurity.

Hoe meer geheimen, hoe lastiger het is om ze te houden. In jouw systeem heb je al twee geheimen: Je algoritme en je sleutel (als je een sleutel hanteert). Daarnaast is de veiligheid van je cryptosysteem bepaald niet zeker tot het door experts op dat gebied is beoordeeld.

Het beste is het nog echt om geteste en door experts beoordeelde algoritmes te gebruiken en alleen de sleutel geheim te houden. Dat is makkelijker en uiteindelijk nog veel veiliger ook.

[ Voor 49% gewijzigd door Gerco op 21-01-2007 22:15 ]

[Cartman!]

Denk alleen dat t niet makkelijk zal zijn om je eigen algoritme te schrijven... iemand misschien voorbeelden of tips hierover ?

[Confusion]

Soultaker schreef op zondag 21 januari 2007 @ 13:01:
verwisselt hashfuncties en encryptie

Tjah, het zou niet de eerste keer zijn dat je iemand een methode de name "md5Encrypt" zie geven. En als je vraagt waar de decryptie-methode is, dan krijg je niet-begrijpende blikken.

[DroogKloot]

Cartman! schreef:
Denk alleen dat t niet makkelijk zal zijn om je eigen algoritme te schrijven... iemand misschien voorbeelden of tips hierover ?

Nee, je eigen crypto-systeempje bouwen is juist erg makkelijk, relatief gezien. Wiskundig keihard onderbouwen dat het veilig is, aan de andere kant, is HEEL moeilijk, en dat is de reden dat je toch beter kunt vertrouwen op algoritmes die tien, twintig, of zelfs dertig jaar analyse hebben doorstaan door mensen met een PhD in wiskunde.

[Verwijderd]

Verwijderd schreef op zondag 21 januari 2007 @ 19:43:
[...]

er is toch een algoritme waarvan wiskundig is bewezen dat het onkraakbaar is?

Klopt, het zogeheten one-time pad:

http://nl.wikipedia.org/wiki/One-time-pad
http://en.wikipedia.org/wiki/One-time_pad

edit:
verkeerde gequote

[ Voor 33% gewijzigd door Verwijderd op 22-01-2007 02:30 ]

[Onbekend]

Verwijderd schreef op maandag 22 januari 2007 @ 02:28:
Klopt, het zogeheten one-time pad:

http://nl.wikipedia.org/wiki/One-time-pad
http://en.wikipedia.org/wiki/One-time_pad

1 regel daaruit:
De lengte van de sleutel dient minstens even lang te zijn als de te vercijferen gegevens.

Dat is inderdaad een van de eisen voor een onkraakbare code.
Maar als ik een bestand van 1MB heb, dan moet ik in mijn sleutel een miljoen tekens hebben!

[Confusion]

flowerp schreef op zondag 21 januari 2007 @ 20:51:
Als je er vanuit gaat dat jouw DB safe is, en je wilt alleen attacks voorkomen d.m.v. collisions die geprobeerd worden, dan zou je ook in code iets specificieks met het wachtwoord kunnen doen, bv om en om bepaalde karakters erin weven. Bv, "test" wordt dan "t#e@s*!t" oid. Als alleen je DB het zwakke punt is, en niet je sourcecode dan zou dat ook tegen rainbow lookups kunnen helpen.

De gebruikelijke manier om dat te bereiken is het gebruiken van een salt

[DexterDee]

Verwijderd schreef op zondag 21 januari 2007 @ 19:48:
[...]


Nee.

HackU : nee, want dat heeft er helemaal niets mee te maken. Brute forcen is mogelijk met ELK hash algoritme, van nu of de toekomst. Dat heeft niks te maken met de recent ontdekte zwaheid.

Het is welliswaar geen hash algoritme, maar er is een heel simpel encryptie algoritme die in theorie onkraakbaar is, alleen heeft deze een aantal praktische bezwaren.

Het betreft de One-Time Pad encryptie. Door een unieke tekenreeks te gebruiken die even lang is als de tekst die encrypted moet worden bereik je een onkraakbare encryptie. Doordat elke letter anders en random gecodeerd is, kun je niet bruteforcen. Voorbeeld:

te coderen: poes
key: hond
encrypted (hex): 18 00 0B 17

Doordat de sleutel even lang is als de te coderen tekst zou de uitkomst van een andere sleutel ook evengoed een willekeurig ander 4 letter woord kunnen zijn:
kees, piet, kaas, blok, peer, sint, ....

Bruteforcen wordt hiermee onmogelijk, omdat willekeurige sleutels valide namen opleveren en je zonder sleutel nooit weet welke de juiste zou moeten zijn.

Praktisch is deze encryptie slecht uit te voeren, want je zal de ontvanger van je encrypted text ook de sleutel moeten geven. Deze is altijd even lang als datgene wat je versleutelt. Een bestand van 10mb heeft dus ook een 10mb sleutel nodig. Afgezien van de logistieke problemen moet je de sleutel natuurlijk ook op een veilige manier overbrengen. Daarnaast als je gebruik maakt van een random number generator om de key te maken, ben je nog steeds in de praktijk kwetsbaar, omdat er maar weinig generators zijn die echte random nummers kunnen uitgeven.

[Rukapul]

DexterDee schreef op maandag 22 januari 2007 @ 11:26:
[...]

Het is welliswaar geen hash algoritme,

Waarom post je in een draad over cryptografische hash algoritmen een uitleg over hoe OTP encryptie werkt?

Een OTP biedt confidentialiteit, een hash algoritme niet (maar kan bijdragen aan integriteit/authenticiteit).

[ Voor 17% gewijzigd door Rukapul op 23-01-2007 18:07 ]

[MSalters]

SH4D3H schreef op zondag 21 januari 2007 @ 19:56:
[...]
Zou het gebruik van beide hashes [MD5 en SHA-1 - MS ] tesamen zoiets niet op kunnen lossen.
Je wilt natuurlijk niet het echte wachtwoord in de database, maar je zou wel de MD5 én SHA-1 op kunnen slaan van het origineel.

Nee - zie Wikipedia. Samen zijn ze net zo sterk als de sterkste van de twee; dwz. de zwakste voegt helemaal niets toe.