Ik weet niet hoe groot de NTLM hashes zijn, maar destralak heeft zeker een punt dat de hash ook van belang is. Die 55 biljoen komt overigens gewoon van het aantal mogelijke strings van 8 karakters gegeven een bepaalde tekenset van zoiets 52 tekens, 52^8 is ongeveer 55.000.000.000.000. Dat vertaalt naar grofweg 2^46 mogelijkheden oftewel 46 bits hashes minimaal. Als je speciale tekens en cijfers gebruikt zou je tot zoiets 80 bruikbare tekens kunnen komen geloof ik, bij dezelfde lengte 80^8, dan heb je minimaal een 51 bits hash nodig.
Als de hash bijvoorbeeld maar 56 bits groot zou zijn is een wachtwoord van 12 karakters al onzinnig geworden omdat je sneller een hash collision te pakken hebt dan het wachtwoord zelf. Ieder extra karakter dat je wachtwoord langer is maakt het aantal mogelijkheden voor een bruteforce aanval in dit voorbeeld een factor 52 groter, oftewel iets minder dan 2^6, dus tussen de 5 en 6 bits. Voor een 56 bits hash zou dus een wachtwoord van 10 karakters net zo sterk zijn als de onderliggende hashes (brute-force, dat wel). Bij een wachtwoord van 12 karakters groot zul je statistisch gezien veel eerder een collision vinden (waarmee je dus net zo goed kunt inloggen) dan het wachtwoord zelf.
Bij SHA 512 zouden wachtwoorden tot zoiets 80 karakters extra bescherming bieden, maar omdat bijna niemand zo'n lang wachtwoord kan onthouden worden het ofwel zinnen die dictionary based te raden zijn, of als het een korter wachtwoord is gaan we toch weer brute-force het wachtwoord zelf raden, in plaats van de hash. De beste bescherming is in dat geval een hash functie die erg rekenintensief is, waardoor het aantal pogingen per seconde fundamenteel beperkt wordt gegeven bepaalde hardware.
Het lijkt mij dan ook dat er fundamenteel andere algoritmes gebruikt moeten worden voor inloggen dan bijvoorbeeld SSL. Een inlogpoging mag best een paar milliseconden rekentijd kosten op high-end hardware, op hele simpele low-end hardware zou zelfs een seconde nog net acceptabel zijn in het begin. Bij SSL moet er relatief veel data versleuteld worden, waarbij een server ook bepaalde performance moet kunnen leveren, dus daar zou zo'n algoritme onacceptabel zijn. SHA-512 lijkt me een hash die gebouwd is om vrij snel gecontroleerd te kunnen worden en toch de kans op collisions zo klein mogelijk te maken, voor wachtwoorden zou ik liever iets anders zien.
Computers worden weliswaar steeds sneller, maar voordat wat nu op high-end hardware in millisecondes gedaan kan worden weer op nanoseconde schaal zit ben je toch zo'n 20-30 jaar verder, genoeg om voorlopig even veilig te zijn, zelfs met relatief korte wachtwoorden
[Reactie gewijzigd door Bas van der Doorn op dinsdag 23 oktober 2007 10:32]
ofwel zinnen die dictionary based te raden zijn
Dat hoeft natuurlijk niet. Als je er 1 cijfer en een uitroepteken ofzo er in doet kom je nergens met je dictionary.
De beste bescherming is in dat geval een hash functie die erg rekenintensief is
Als de veiligheid van je wachtwoord afhangt van de snelheid van je computer heb je een slecht systeem. De snelheid van computers verdubbelt om de zoveel maanden dus dan loop je na een tijd achter. Daarnaast zal er bij gebruik van dedicated hardware het nog eens enorm veel sneller kunnen dan een standaard cpu.
Het lijkt mij dan ook dat er fundamenteel andere algoritmes gebruikt moeten worden voor inloggen dan bijvoorbeeld SSL
Weet jij meer dan al die experts op dit gebied die de huidige banksystemen als veilig beschouwen ?
genoeg om voorlopig even veilig te zijn, zelfs met relatief korte wachtwoorden
Korte wachtwoorden zijn gewoon niet veilig dus die moet je nooit gebruiken. Daarnaast is een systeem wat maar zo kort veilig is ook niet bepaald goed te noemen want super computers van nu bezitten de snelheid van de gewone computers van over 20 jaar.
Als je zegt dat het wachtwoord te snel te testen is dan doe je gewoon een wachttijd van een seconden tussen elke poging.
Als je denkt dat een wachtwoord te snel te raden is kan je het systeem gewoon uitbreiden zodat de kans op een kraak kleiner wordt en de kraakttijd toeneemt. Dat maakt een systeem niet fundamenteel onveiliger. Een systeem creeeren dat afhankelijk is van de huidige stand van techniek... DAT is pas onveilig want niets gaat zo snel als de technologische ontwikkeling.
Daarnaast is de relatie die je trekt tussen de lengte van je wachtwoord en de kans op een collision natuurlijk onzin als je het wachtwoord niet weet zoals Bef al zei. Op zich klinkt je verhaal leuk, alleen klopt er niet zo heel veel van.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
Al jaren is het mogelijk om door middel van een brute force-techniek wachtwoorden te achterhalen. Een groot nadeel hiervan is dat dit veel tijd kan kosten. Een Windows Vista-wachtwoord dat bestaat uit acht letters, zowel onderkast als kapitalen, en versleuteld is met ntlm kent al 55 biljoen mogelijke tekenreeksen. Een dualcore cpu kan maximaal tien miljoen wachtwoorden per seconde berekenen, aldus ElcomSoft, wat zou betekenen dat het kraken van een wachtwoord maximaal twee maanden zal duren. De nieuwe software zou deze tijd echter terugbrengen naar maximaal vijf dagen.
09:57
09:06
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
.
