Mogelijkheid ontdekt om hashing te omzeilen

De Duitse onderzoekers Stefan Lucks en Magnus Daum hebben een techniek gevonden om twee PostScript-documenten te voorzien van eenzelfde MD5-hashcode. De methode maakt gebruik van de mogelijkheid om testroutine in een PostScript-document te programmeren. Enige tijd geleden werd bekend dat het relatief eenvoudig was voor een computergebruiker om binnen een paar uur twee willekeurige tekenreeksen te genereren die dezelfde hash hebben, welke we voor het gemak R₁ en R₂ noemen. Het voorkomen van twee verschillende tekenreeksen met dezelfde hash wordt een 'collision' genoemd. Een andere tekortkoming van het MD5-algoritme is dat als aan deze twee tekenreeksen dezelfde informatie, aangeduid als 'S', wordt toegevoegd, de twee nieuwe reeksen - R₁S en R₂S - dezelfde hash-code zal geven. Deze toegevoegde informatie is een uitgebreide testroutine, dat controleert of de tekenreeks aan het begin van het document - het enige verschil tussen de twee documenten - gelijk is aan R₁. Als dit het geval is, wordt tekst T₁ weergegeven, zoniet, wordt tekst T₂ weergegeven. De twee dia's onderaan dit artikel laat voorgaande verhaal in formuletaal zien.

Dit resulteert in twee documenten met dezelfde hashcode die verschillende informatie laat zien. De methode hoeft niet beperkt te blijven tot het PostScript-bestandsformaat; macro's in Word-documenten en programma's kunnen bij een hash verschillende data presenteren. Een hash wordt onder andere gebruikt om bestanden van een unieke code te voorzien, waaraan een digitale handtekening kan worden gekoppeld. Op die manier kan worden voorkomen dat iemand de handtekening van het ene document gebruikt voor een ander. Met de ontdekking van de methode om twee documenten van dezelfde hash te voorzien is dit wèl mogelijk, waardoor deze methode van signeren onbetrouwbaarder wordt. De twee onderzoekers zijn van mening dat deze ontdekking een serieus gevaar gaat worden zodra er efficiëntere methodes worden gevonden om MD5- en SHA1-hashcollisions te berekenen.

Reacties (64)

[Leknaas]

md5 bestaat uit 32 tekens, in totaal zijn er dan iets van 1,017 x 10^49 mogelijkheden. Dit is een beperkt aantal want iedereen kan natuurlijk een ontelbaar aantal verschillende wachtwoorden verzinnen...

Voor het beveiligen van documenten, mappen, toegang tot vanallerlei informatie is md5 ook niet bedoeld.

Echter blijft md5 heel interessant voor webapplicaties, inloggen van accounts e.d. md5 zal daardoor ook niet snel gaan verdwijnen. De kans dat je op een website een wachtwoord invult waaruit precies dezelfde hash komt dan het oorspronkelijke wachtwoord is echt ontzettend klein.

En als iemand je account kraakt is dat natuurlijk niet echt een ramp. Als je meer gevoelige informatie op het internet hebt staan moet je dat natuurlijk niet met een php scriptje gaan beveiligen.

Verder staat in de titel dat er een mogelijkheid is ontdekt om hashing te omzeilen, maar in feite is het eenzelfde hash te produceren waardoor je toegang krijgt.

[Voutloos]

32 hexadecimale karakters. 2^128 dus. (3,4 x 10^38). Dit zijn nog steeds veel mogelijkheden, maar het is al een heel stuk beter behapbaar dan het aantal dat jij zegt.

Let ook op dat deze aanval niet op 1 specifieke hash mikt, ze zoeken puur 2 strings met een collision. Dankzij The Birthday Paradox is die zoektocht makkelijker dan het zoeken van 1 exacte hash.

Sterker nog, een puntje wat niet toegelicht wordt in de nieuwspost of het artikel: Waarom zijn R1 en R2 niet te hergebruiken voor elk willekeurig postcript file? Als je eenmaal een collision hebt en de code voor een postcript file welke 2 documenten kan bevatten, kan je dan misschien wel voortaan nieuwe postcriptdocumenten maken zonder enig rekenwerk? Volgens Dia 1 kan dat.

[The Noid]

Het lijkt mij inderdaad ook. Als je eenmaal een R1 en R2 hebt die dezelfde hash geven dan kan je die eindeloos hergebruiken.

[RwD]

Ach, als je challenge-response gebruikt is het niet eens heel erg. De hash van je wachtwoord gaat dan nooit over de lijn maar iedere keer een andere code. Veilig zat, want al stuur je dezelfde hash als waarmee iemand 1 seconde geleden inlogde; als er goed geprogrameerd is dan is die hash al lang niet meer geldig...

Dus ik ziet dit geen probleem worden voor inlogscripts...

[Anoniem: 92624]

en als iemand je account kraakt is dat natuurlijk niet echt een ramp.

Webbased Intranet/Extranet met business- en toekomstplannen van een groot bedrijf?

[Voutloos]

Voor iedereen die het over wachtwoorden, inlogsystemen en php scriptjes heeft: Deze vinding heeft daar 0,0 mee te maken.

Het gaat puur om het makkelijk kunnen maken van 2 strings met een collision, iets wat niet zo mogen bij een veilige hashfunctie (dit is 1 vd eigenschappen van een veilige hash functie. Iedereen snapt dat er collisions zijn, maar je mag ze niet met gamak vinden). Dit kan misbruikt worden bij hashes over data, zoals het postscript voorbeeld, maar maakt het _niet_ makkelijker om een wachtwoord te vinden welke een specifieke hash oplevert.

[Jace / TBL]

Lijkt me niet rampzalig, er zouden pas echt problemen zijn als je bij ieder willekeurig bestaand document (of andere data, passwords e.d.) een ander document (c.q. data) kon genereren met dezelfde md5 hash.

[TD-er]

Even een simpel voorbeeld waarmee de p2p gebruikers niet zo blij zullen zijn.
De meeste p2p progsels verdelen de files in een x-tal blokken die elk hun eigen checksum hebben.
De files worden geidentificeerd door hun checksum en tevens is het een verificatie om te zien of de file compleet binnen is.

Aangenomen dat je op een gegeven moment dus vrij eenvoudig een collision kunt berekenen, kunnen instanties als Brein en de BSA de p2p netwerken vervuilen met files die dezelfde hashes hebben, maar dus niet werken.

[Jace / TBL]

Aangenomen dat je op een gegeven moment dus vrij eenvoudig een collision kunt berekenen

Dat is een foute aanname

Je kunt geen collision bij een bestaand bestand genereren. Je kunt alleen twee nieuwe bestanden genereren die colliden, maar daarbij kun je niet forceren dat die een van te voren gegeven md5 hash hebben.

[Olaf van der Spek]

Aangenomen dat je op een gegeven moment dus vrij eenvoudig een collision kunt berekenen

BitTorrent gebruikt al SHA1 (160 bits) in plaats van MD5. Tenzij SHA1 compleet onderuit gaat, kun je 'simpel' een variant met een langere hash gebruiken.

[TD-er]

het was ook meer als voorbeeld genoemd en ik had expres niet een bepaald p2p-netwerk genoemd.
Daarnaast is zo'n netwerk vrij traag om om te schakelen naar een nieuwe versie, aangezien je anders vrij veel gebruikers verliest.
Het is dus zeker een mogelijkheid om p2p-gebruikers (tijdelijk) te ontmoedigen.

[Goldwing1973]

langere hash gebruiken....

Hoe stoned wil je me hebben?? sjeez...

[bassekeNL]

Ik geloof dat er in SHA-1 ook al een weakness was gevonden.

Yup:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

[The Noid]

Nee, het is nog steeds niet makkelijk om bij een willekeurig bestand een ander bestand te genereren met dezelfde md5 sum.

Het is mogelijk om binnen "een paar uur" 2 strings te genereren die dezelfde hash opleveren. BEIDE strings worden dus door de "aanvaller" gegenereerd.

Voor p2p netwerken is er dus nog steeds geen probleem.

[Fuzzillogic]

Ik kan me zo voorstellen dat je hiervoor bijv. ook prima de EXIF of commentaarruime in een JPEG kunt misbruiken. Het valt niet op als daar wat 'rommel' in staat.

Heel veel bestandsformaten bieden wel ergens plaats voor meta-data. Het kan dus weldegelijk rampzalig worden!

[Jace / TBL]

Ik kan me zo voorstellen dat je hiervoor bijv. ook prima de EXIF of commentaarruime in een JPEG kunt misbruiken. Het valt niet op als daar wat 'rommel' in staat.

Heel veel bestandsformaten bieden wel ergens plaats voor meta-data. Het kan dus weldegelijk rampzalig worden!

Nee, zo werkt deze "vulnerability" niet. Je kunt niet een gegeven bestand een beetje aanpassen of er iets aan toevoegen zodat het resultaat een bepaalde gewenste md5 hash heeft.

[The Noid]

Nee, dit werkt alleen bij bestandsformaten waar een macro in zit die kan bepalen wat er weergegeven wordt. Alleen meta informatie veranderen is dus niet genoeg.

[Anoniem: 96271]

Het is idd mogelijk om 2 verschillende JPEG bestanden een zelfde hash te geven, op voorwaarde dat ze wel dezelfde beeld informatie bevatten. Het gaat dus voorlopig alleen om bestanden met een actieve inhoud (die 2 verschillende inhouden kunnen hebben)

[gp500]

MD5 is makkelijk te kraken en het wordt wereldwijd gebruikt.
Het is achterhaald en moest in 199x al vervongen worden volgens het schema.
Maar ze blijven deze verouderde manier toepasen.

[frickY]

Onzin.

MD5 is een one-way hash. Het is onmogelijk om uit de hash de orginele invoer terug te halen. Van 'kraken' is dus zowieso geen sprake.
Dat je deze uitspraak doet doet mij denken dat je geen idee hebt waar hashing voor gebruikt wordt, niet als codering in ieder geval.

[Janoz]

Misschien is het voor sommige mensen handig wanneer ze even ietsje beter doorlezen wat er nu eigenlijk gedaan is. Ik zie hier in de reacties veel geneuzel over dat MD5 niet meer veilig is of dat er nu allemaal dummy content verschijnen kan omdat je van bestaande documenten een andere versie kunt maken met dezelfde hash.

In principe hebben ze het volgende bedacht (in javascript variant):

---
var = 'x';
if (var == 'x') {
document.write('De complete content van het ene bestand');
} else {
document.write('De complete content van het andere bestand');
}
--
De onderzoekers hebben vervolgens een manier gevonden waarop ze enkel de eerste karakters aan kunnen passen zonder dat de hash code veranderd.
--
var = 'x';
-->
xyz = 'x';
--
Zodra je dit bestand door de browser laat uitvoeren kun je dus 2 verschillende versies voor je neus krijgen. omdat de test die bij de if wordt uitgevoerd een ander resultaat oplevert (var is immers niet meer gelijk aan x omdat var nu helemaal niet bestaat)

MAAR:
- het is alleen mogelijk met documenten die macro of andere uitvoerende mogelijkheden hebben voor ze worden afgedrukt. Office documenten, html, pdf en (zoals in de nieuws post) ps zijn wel kwetsbaar terwijl mp3, jpeg, gif dat juist weer niet zijn.
- Je kunt alleen een collision creeren als je zelf de bron van beide versies bent. Het is niet mogelijk om een reeds bestaand document te 'impersonaten'. Je kunt wel een bestaand document als bron gebruiken voor een dubbel bestand, maar deze heeft dan niet dezelfde hash als het orgineel.
- Beide versies van het document zijn nog keurig te achterhalen omdat ze beiden binnen het document opgeslagen zitten.
- Het heeft helemaal niks te maken met reeds bestaande hashes van bestanden of wachtwoorden.

[imp4ct]

Ik weet dat mijn forum een MD5 hash gebruikt om z'n wachtwoorden op te slaan. Moet ik mij nu gaan zorgen maken dat deze wachtwoorden makkelijk gekraakt kunnen worden ofzo, want ik veronderstel toch dat ieder zelfrespecterend bedrijf dat forum templates aanbied toch ergens wel wilt zorgen dat z'n beveiliging op punt staat.
'k Maak gebruik van een Ikonboard.

En nu deze info geweten is wat heeft dit dan voor gevolgen voor de MD5 hash, gaat ze worden aangepast of hoe gaat zoiets in z'n werk ??

[JeRa]

Het achterhalen van de originele string uit een MD5 hash is tot dusver nog niet mogelijk zonder brute forcing. Zolang je gebruikers dus een redelijk goed wachtwoord hebben gekozen, zal de tijd die het kost om vanuit de MD5 hash terug te rekenen groot zijn.

Het probleem is echter dat er een manier is gevonden om twee (lichtelijk) verschillende strings eenzelfde MD5 hash te laten opleveren. Dit is dus niet van toepassing op de wachtwoorden van gebruikers, aangezien je daarvoor dus eerst het wachtwoord zelf moet weten voordat je een soortgelijke MD5 hash kunt maken. Ik geloof zelfs dat de methode alleen snel is op strings van 1024 bits of iets in die richting.

Als je echt paranoïde bent kun je zowel MD5 als SHA-1 toepassen om documenten of wachtwoorden te verifiëren. De kans dat eenzelfde tekenreeks zowel een collision veroorzaakt in MD5 als in SHA-1 is enorm klein

[Anoniem: 119061]

Zucht...

Het is niet mogelijk om de oorspronkelijke string uit een MD5 hash te halen als deze groter is dan de lengte van de hash zelf.

Van b.v. een 100 KB bestand blijven als hash slechts 32 karakters over. Er is dus een zeer groot aantal mogelijke 100 KB bestanden die dezelfde hash hebben. Je weet dus nooit wat de oorspronkelijke bron geweest is, je kunt alleen maar een aantal (afhankelijk van de grootte van het input bestand) mogelijke inputbestanden afleiden (met veel moeite).

[Jace / TBL]

Het is niet mogelijk om de oorspronkelijke string uit een MD5 hash te halen als deze groter is dan de lengte van de hash zelf.

Zelfs niet als de oorspronkelijke string kleiner is dan de hash zelf.

[TheOneLLama]

En je zal niet de eerste zijn. Zo maakt bv SSL gebruik van zowel SHA1 en MD5 op dezelfde data.

I_M_P_A_C_T: Het heeft niet zoveel gevolgen voor jou. Deze aanval is bedoeld om als je toegang hebt tot zowel de data als de hash, nieuwe data met dezelfde hash te maken.

Dus, stel jou password is r00t. Dan zou ik -als ik jou MD5 hash weet- een ander password kunnen maken waarmee ik kan inloggen. Wat ik daar verder aan heb, is nogal een raadsel in jou geval.

[RwD]

Zoek op wat voor methode Ikonboard gebruikt. Ikzelf gebruik altijd challenge-response waarbij nooit twee keer dezelfde hash gebruikt wordt. Zolang kwaadwillende personen niet de toegang tot je database hebben is het best veilig. Kunnen ze in je database dan maakt het sowieso niet zoveel uit wat je beveiliging eigenlijk is...

Enige nadeel van challenge response is dat het wachtwoord ongecodeerd opgeslagen wordt in de database. Ik sla de md5 er van op zodat het wachtwoord niet direct leesbaar is, maar die md5 is eigenlijk het ongecodeerde wachtwoord

[Mentalist]

Volgens mij hoef je je geen zorgen te maken. Die lijst MD5 sums van je forum publiceer je toch niet? Dan kan je er sowieso al niks mee.

[martijnvanegdom]

Van beveiliging heb je duidelijk geen kaas gegeten..

De essentie is dat de md5 hashing minder betrouwbaar word. Het is dus mogelijk dat twee strings die enigzins variëren toch dezelfde hashing hebben.. Daardoor word de code een stuk minder sterk

[Mentalist]

True, maar ik vraag me af hoe erg dát is voor de beveiliging van je forum. Dan is er niet 1 wachtwoord geldig (ervanuitgaande dat niet op lengte gecheckt zal worden, want het aantal wachtwoorden met dezelfde lengte én dezelfde hash zal helemaal zeldzaam zijn) maar dus meerdere, alleen zijn alle "andere" wachtwoorden, waarschijnlijk volslagen random bullshit. Goed, iets meer kans met een bruteforce attack, maar verder zou ik me nog steeds geen direct zorgen maken dat alle wachtwoorden morgen op straat liggen.

[Chesta]

Nee, want het is onmogelijk om achter de hash code te komen die in de database staat, als je geen database toegang hebt.

De forums zijn zo geprogrammeert dat je via php moet praten, en dat is dan de beveiliging.

Het enige wat overblijft is brute force, waarmee je theoretisch alle wachtwoorden mee kunt kraken (maar in de praktijk heb je daar geen zin in )

[Orphix]

Dit betekent dus niet dat je bv in een PDF factuur eventjes een nulletje weg kan halen en dan via een truukje dezelfde hash terugkrijgt. En dus is het gebruik van een hash om bestanden te controleren nog steeds vrij geldig.

Misschien is het wel mogelijk een reeks te creeren met dezelfde hash, maar dan moet die reeks ook wat betekenen voordat je ermee kan fraudere/hacken/etc!

[Anoniem: 147045]

Helaas is het punt van bovenstaand artikel nu precies dat dat dus wel kan . Althans, je kan twee PDF facturen maken, een met een nulletje meer dan de ander, maar met dezelfde hash.

[Orphix]

Je hebt idd gelijk. Ik heb het artikel nog even doorgelezen en daar werd het me duidelijk, dit kwam niet echt uit het nieuwsbericht naar voren.

[Anoniem: 45514]

Wat het betekend is uitsluitend dat deze methode aantoond dat het mogelijk is om (uiterlijk) zeer verschillende documenten te creeren met dezelfde hashcode.

Je kunt daarom deze md5 hash niet gebruiken als bewijs dat document1 hetzelfde document is als document 2 omdat het dezelfde hashcode heeft. (Meestal weet je van een van de documenten alleen de hashcode).

Je weet echter wel nog steeds dat de bron van beide documenten waarschijnlijk gelijk is (nodig voor vinden collision). Daarnaast is het natuurlijk vrij opvallend wat er gebeurd als je naar de code van het postscript bestand kijkt.

[Anoniem: 2072]

MD5 is al heel lang niet meer secure.
Maar zo lang de hashes niet zichtbaar zijn voor 3rd parties maakt het niet veel uit (want dan moet je gewoon brute forcen).

ps, SHA1 is ook al een tijdje niet meer secure. Het combineren van meerdere unsecure hash algoritmen maakt het wel een (heel) stuk moeilijker om een collision te vinden.

[pierre-oord]

@B_Muerte:

Alleen als je het misschien in stukjes doet, dus eerste 3 tekens password md5 en laatste 4 dan SHA1.

Ik bedoel:
Password 1 > MD5hash1
Password 2 > MD5hash1

Is toch wat hier wordt verteld?
MD5hash1 > SHA1
MD5hash1 > SHA2

Dat zou dus niets uitmaken...?

[Voutloos]

De mensen die het over meerdere hash functies combineren hebben bedoelen inderdaad dat de originele string voor al deze functies de feed is. Identieke strings hashen levert uiteraard altijd dezelfde digest op en daarom kan je inderdaad geen digest van een collision gebruiken voor een volgende hash functie.

[Anoniem: 39126]

Dit bewijst toch wel dat MD5 echt gekraakt is. Dit is niet meer een theoretische mogelijkheid maar een duidelijk praktisch bewijs: echt verschillende werkende documenten kunnen maken met dezelfde MD5, dat betekent dat die hele hash daarmee dus waardeloos is geworden.

De vraag is alleen nog wel hoeveel rekentijd ze dat heeft gekost...

[BramT]

md5 is niet gekraakt - het is geen codering en is ook nooit zo bedoeld. md5 genereert simpelweg een hash wat weer gebruikt kan worden in andere functies/toepassingen.

Verder is het nog steeds niet waardeloos, d'r zijn nog talloze andere toepassingen te verzinnen waarvoor md5 compleet voldoet.

D'r is nu gewoon aangetoond dat het ondertekenen van documenten die iets aan scripting kunnen doen niet meer betrouwbaar hoeft te zijn. Maar zet b.v. scripting/macroing in je 'reader' uit en je hebt weer geen probleem... etc.. Dit is iets erg specifieks, niet meteen heel 'md5' afvallen dus aub

[dr kriebel]

Je hebt inderdaad gelijk, je moet MD5 niet gebruiken voor wachtwoorden. Het probleem is echter dat dit wel vaak voorkomt.

[Jace / TBL]

Je kunt md5 prima gebruiken voor wachtwoorden.

Het is momenteel praktisch alleen mogelijk om twee verschillende stukken data met dezelfde hash te generen. En niet om bij een gegeven hash een stuk data te genereren met die hash.

[dr kriebel]

Reactie voor Jace / TBL:
Lijkt mij geen goed plan, om MD5 voor wachtwoord te gebruiken. Je kunt kant en klare rainbowtables kopen, waarmee je MD5 strings gemakkelijk kunt ontcijfereren:
http://rainbowtables.net/
Anders kun je het hier gratis proberen:
http://passcracking.com/
En zo zijn er nog een zooitje sites waarmee het mogelijk is, om in ieder geval MD5 wachtwoorden tot iets van 12 karakters te ontcijferen.

edit:

in combinatie met de 'salt-methode' kun je MD5 in ieder geval al veiliger gebruiken voor wachtwoorden, maar niet optimaal

[Quarks]

Nou dan doe je in het vervolg toch zo:
md5( md5( pwd ) );

Laat ze die maar lekker kraken!

[H!GHGuY]

@Quarks:

dat zal niet helpen want dan zal iemand wel een md5(code) vinden die een collision vormt voor code ~ md5(pwd)..

[RetepV]

Of ik ben gek, of dit is complete onzin.

Wat gebeurt er met wachtwoorden...

Als jij een wachtwoord invoert in het systeem, dan maakt die er een hash van en slaat die op.

Als je dan ergens weer je wachtwoord moet invoeren (om in te loggen bijvoorbeeld), dan voer je je wachtwoord in en wordt die weer gehashed.

Dan worden de hashes met elkaar vergeleken en als ze gelijk zijn, dan wordt er van uit gegaan dat het ingevoerde password gelijk is aan het opgeslagen password.

Een hash is one-way. Je kunt vanuit een hash niet een password terughalen.

Je kunt wel brute-force een password zoeken waarvan de hash overeenkomt met de hash van het password. Maar dan moet je dus eerst toegang tot het systeem hebben, tot de password hashes. Vroeger in Unix was dat makkelijk, tegenwoordig al een stuk minder .

De enige andere mogelijkheid die je over hebt om via een dictionary een half miljoen 'well-known' passwords uit te proberen via het login proces.

[Olaf van der Spek]

md5 is niet gekraakt - het is geen codering en is ook nooit zo bedoeld.

Eh, en waarom zou iets dat geen codering is niet te kraken?
MD5 is bedoeld als secure hash waarbij een van de eigenschappen is dat het genereren van twee verschillende documenten met dezelfde hash ondoenlijk is binnen 'afzienbare' tijd.
Die eigenschap geldt nu dus niet meer en dus is MD5 'gekraakt'.

[Gepetto]

Ik dacht eigenlijk dat dit al veel langer kon. Was het niet zo dat op P2P netwerken ook gebruikt gemaakt wordt van hash codes om met name mp3 bestanden te voorzien van een handtekening.

En dat de muziekindustrie al lang een methode had gevonden om deze netwerken vol te pompen met verminkte bestanden (vol met ruis) met toch dezelfde hashcode als het "origineel"?

[Olaf van der Spek]

Nee, dat werkte bij Kazaa omdat Kazaa alleen de eerste 30 s (een bepaald aantal bytes) van MP3s checkte.

[H!GHGuY]

Dit bewijst toch wel dat MD5 echt gekraakt is.

nee hoor... je moet rekening houden dat het wel een tijdje duurt vooraleer je zo'n collision kan vinden.
dus als je dit wil gebruiken voor beveiliging maak je gewoon dat deze slechts voor korte tijd geldig is

[dr kriebel]

Niet echt zoals het ooit bedoelt was nee.
- Er is ook al bekend dat je wachtwoord langer dan een aantal tekens moet zijn (ik geloof zelfs , omdat anders binnen een aantal dagen alle combinaties uit te proberen zijn. MD5 is trouwens nooit echt geschikt geweest voor wachtwoorden, maar bij PHP kun je het wel zodanig gebruiken bv.
- Verder is het al gekraakt dankzij de rainbowtables
- En vergeet niet de vele websites die al kant en klare databases verkopen, dan wel aanbieden

edit:
hoofdletters

[Anoniem: 30917]

[quote]

- Er is ook al bekend dat je wachtwoord langer dan een aantal tekens moet zijn (ik geloof zelfs , omdat anders binnen een aantal dagen alle combinaties uit te proberen zijn.
[quote]
Niet echt relevant, dat wachtwoorden te kraken zijn is logisch, het gaat erom hoeveel mogelijkheden per seconde te proberen zijn. Bij een systeem dat 3 pogingen toestaat per 5 minuten is een wachtwoord van 8 voldoende.

MD5 is trouwens nooit echt geschikt geweest voor wachtwoorden, maar bij PHP kun je het wel zodanig gebruiken bv.

Het artikel gaat helemaal niet over wachtwoorden, maar over fingerprints.

[wica]

De vraag is alleen nog wel hoeveel rekentijd ze dat heeft gekost...

Dit geld voor iedere beveiliging.

Maar denk ook wel dat md5 geschiedenis is.

[Anoniem: 53573]

Dat er dezelfde MD5 Hashes van verschillende bestanden gemaakt kan worden is natuurlijk logisch. Anders hadden we immers de allerbeste compressie methode ooit....

Mensen die zich zorgen maken om een wachtwoord in een forumpje hoeven zich echt geen zorgen te maken. Allereerst ziet alleen de Webmaster de bewuste Hash, en die kan toch al bij je account...hij ziet nu alleen niet je wachtwoord. Een redelijk wachtwoord verzinnen is ook met een Hash natuurlijk noodzakelijk...

[mosymuis]

Dat er dezelfde MD5 Hashes van verschillende bestanden gemaakt kan worden is natuurlijk logisch.

Dat het theoretisch kon, stond direct al vast aangezien MD5 is gebaseerd op afronding. Hoe lang het document ook is, je krijgt nooit meer of minder dan 32 karakters terug. Dat het nu praktisch ook met zoveel gemak en snelheid kan, is wel iets nieuws.

[schoene]

Mijn inziens is de grootste zwakheid van MD5 toch niet dat je makkelijk 2 willekeurige strings met dezelfde MD5-hash kan vinden. Aangezien het aantal hashcodes beperkt is, moest dit vroeg of later relatief eenvoudig te doen zijn, alleen maar door pure rekenkracht.

maar wat volgens mij wel de grooste reden is, is dat als MD5(X1) == MD5(X2), er dan ook geldt MD5(X1||S) == MD5(X2||S).

Deze eigenschap alleen al zorgt ervoor dat je MD5 niet zou mogen gebruiken voor encryptie/beveiliging.

[kidde]

Ja, in dat 'toevoeging van info met het behouden van de hash-uitkomst' lijkt mij ook het probleem te zitten.

Op wikipedia kwam ik al tegen dat tegenwoordig Whirpool wordt aanbevolen, en dat SHA2 (>224 bits) ook beter is dan de bestaande SHA(1), maar vooralsnog heb ik helaas geen implementaties gevonden van deze varianten, bijvoorbeeld om m'n wachtwoord voor hard-disk encryptie te hashen.
Niet dat het al mogelijk is het wachtwoord te achterhalen, maar door dit soort berichtjes wordt je paranoiditeit toch gevoed.