Uhmm. niet?
Het is een demonstratie om zo de problemen naar voren te halen om het geheel veiliger te maken.
Dat is het zelfde als wanneer je een bug in os vind waarmee je bijv een buffer overload kan generenen.
Pas als je deze bug zou gaan exploiten ben je verkeerd bezig.
Dit soort demonstratie's zijn alleen maar beter.
Overigens vraag ik me nu wel af waar het einde is...?
Elk algoritme wat de mens bedenkt, kan de mens kraken...
Ik heb een keer een wachtwoord van 6 karakter in MD5 proberen te achterhalen en mijn Centrino Duo T2400 was na 14 uur nog maar bij 3 karakters...Dus zo hard loopt dat volgens mij niet echt...
edit:
Reactie op aartdeheus
na 14 uur nog maar bij 3 karakters...
Lulkoek. Zo werkt het helemaal niet. Google maar eens op rainbowtables.
Ik heb geprobeerd een MD5 hash te decypheren door middel van brute-force. Een vriend van mij had de hash gegeven en gezegd dat het een range van minimaal 4 en maximaal 7 was. De keyspace was [a-z], [A-Z] en [0-9]. Decipheren van hashes gemaakt met 3 of 4 karakters zijn inderdaad zo gedaan. 5 karakters wordt al langer. 6 karakters begint al echt lang te duren, en hierna verder bleek brute-force toch echt niet een oplossing te zijn. ( sidenote: Je hebt inderdaad - zoals daapah onderaan zei - óf alle karakters, óf geen)
Toen zocht ik inderdaad ook naar andere manieren, en toen kwam ik op de rainbowtables + chains. Het idee hiervan is het genereren van alle mogelijke hashes in de range en keyspace die je opgeeft, zodat daarna in een erg snel tempo een hash ge-'decode' kan worden.
Nadeel is dat je een gigantische hoeveelheid data genereert (denk aan 32+ gigabyte). Voordeel is dat je hashes (MD5, SHA-1, ...) binnen een hele korte tijd gevonden heb (minder dan 10 minuten).
heh, dan is je implementatie toch echt fout

mijn oude Athlon 1400 had binnen 923 milliseconden het 4-letterig wachtwoord al gekraakt. Bij jou zou dit dus ruim langer dan 14 uur duren
Verder moet je de kracht van supercomputers/grote clusters/distributed computing _NIET_ onderschatten, daar moeten de algoritmes van tegenwoordig ook redelijk tegen bestand zijn, anders zijn ze nutteloos namelijk.
Lulkoek. Zo werkt het helemaal niet. Google maar eens op rainbowtables.
Zelfs een bruteforce is oneindig-1 maal sneller dan 14 uur voor 3 karakters hoor
Dus geef je laptop iets meer dan een volle dag de tijd, en hij kan min of meer willekeurig elk 6 karakters tellend wachtwoord van bijv. blogs (omdat die wachtwoorden meestal te vinden zijn op de webserver) kraken....
Dat vind ik genoeg reden voor angst en een extra lang wachtwoord

@dataghost: ik had het erover dat hij nog maar 3 van de 6 karakters na 14 uur had. Je hebt of alle karakters, of geen karakters. Dat je alleen het 1e, 3e en 6e karakter weet is echt zo'n hollywood filmpjes verhaal.
@xanderd: Valt wel mee. Er zijn twee methodes om een password te 'kraken'. Offline, waarbij je de hash moet hebben, en je net zolang gaat proberen totdat je een password hebt dat de hash matcht. Dit kan je vervolgens gebruiken om in te loggen. Deze hash achterhalen is vrij moeilijk, omdat die meestal in een of ander backendje word gecheckt tegen een waarde in een database. De tweede methode is online, waarbij je passwords gaat proberen in een inlogveld. Om een password van 6 karakters te bruteforcen, heb je 26^6 mogelijkheden. Als je ervoor zorgt dat er een login timeout van bijv. een uur optreedt na elke 1000 login pogingen duurt het een eeuwigheid voordat je dit wachtwoord achterhaald hebt.
Je angst is dus niet echt gegrond. Met een beetje verstand kun je nog steeds 99,999999999999999% van de mensen buiten houden.
hij bedoelt dat zijn bruteforce op 3 karakters was,
a, b, c...z
aa, ab...zz
aaa
etc.

Dat noem ik een nogal slechte implementatie, aangezien eoa bruteforce die ik een tijd terug heb gebruikt binnen 923 milliseconden ergens ver weg in het alfabet zat, bij de r, op 4 letters. Ik wist toen niet hoeveel karakters het password bevatte, dat weet Fastex wel. Verder maakt dat niks uit voor de rekentijd tot aan 3 tekens.
Vooral de offline methode boezemt mij angst in.
Voor een studie project heb ik eens een klein blogje bijgehouden, en daarvoor gebruikte ik het pakket SimplePHPblog. Dit is zoals de naam al suggereert een recht-toe-recht-aan blog pakketje waar je alleen een PHP enabled server voor nodig hebt. Na een paar kliks kan je aan de slag met bloggen.
Het MD5 gecode pwd bestand zit ergens zeer ondiep, die had ik zo gevonden. Iedereen van mijn klas kon bij de server, hoewel ze niets konden aanpassen konden ze wel de mappen lezen. Dus het pwd bestand downloaden en decrypten zo zomaar kunnen...
Er zijn redelijk veel blogs met zon simpele opzet en bescherming... Ik schat ergens in de honderd duizend...
In ieder geval voor mij genoeg reden om lange niet-alfanumerieke wachtwoorden te nemen.
vaak zie je dat dit soort wachtwoorden in een .php bestand in een commentaar veld staan. Een php script kan er zo wel bij, maar als je het met de browser probeert te benaderen gaat het door de php parser, en zal het commentaar verdwijnen.
Zeg euhm, hoe leuk deze discussie ook is, hij is wel nogal off-topic.
MD5 en SHA-1 hashes kun je niet "achteruit breken", dwz je kan niet op de een of andere manier een password uit een hash genereren. Je kunt het wel brute-forcen, oftewel net zolang proberen totdat je toevallig je goeie gevonden hebt.
Waar het nieuwsbericht echter over gaat, is het feit dat je voor twee bestanden dezelfde hash kan genereren. Een is dan hierbij het orgineel, en de ander gefabriceerd. Dat dat kan is al erg genoeg (hoort absoluut niet te kunnen), maar ze kunnen dus ook ongeveer 25% van die fabricatie een eigen invulling geven (zeer dodelijk). Hiermee kun je dus willekeurige gevens (lees: virus) doen voorkomen alof het bijvoorbeeld install_messenger.exe is, omdat deze dezelfde hash hebben.
"Seperate The lock from the key"
Wat een redelijk vaak gebruikte methode is , is string concaternatie voordat je het crypt.
Mocht de php code in handen vallen van iemand, dan weten ze alleen de concat-string. Mocht de database in handen vallen, dan moeten ze sha1 hash van een string van 100 tekens ontbinden.
Deze 2 houden aardig offline hacks tegen.
Online script, gewoon voordat het wachtwoord word gecontroleerd de thread voor 3 of 4 seconden slepen. Dan word bruteforce al erg moeilijk.
Alleen sociale enginering is lastig te voorkomen, maar ja das niet de schuld van mijn implementiatie
