Eigen Inlog?
Je krijgt dus echt een tabel met
a [hash]
b [hash]
c [hash]
....... (vele hashes verder)
bla_boon [hash]
bla_boom c6a5c55dda637108d317d11024b96436 <- bingo, deze hebben we ook in onze gehackte gegevens gevonden.
Iemand heeft in zijn database het volgende staan:
Gebruiker_1 c6a5c55dda637108d317d11024b96436 (bla_boom)
Gebruiker_2 bdfb4aa7cc60785d05f9792835818eb8 (bla_boek)
Als iemand dus met zijn rainbow tabel aan komt zetten zal hij zien, dat 'bla_boom' resulteerd in de hash: c6a5c55dda637108d317d11024b96436
Daar hoef je helemaal niet de prefix van te weten, dat is gewoon alle mogelijkheden af gaan, dus als je een tabel met md5 hashes van 8 tekens (alle tekens) komt aanzetten, zul je zien dat 'bla_boom' daar tussen staat en ook 'bla_boek'.
Dus als je die eenmaal gevonden hebt, kun je dus de resultaten gaan vergelijken en zie je dus dat er een prefix lijkt te zijn, als je nog een derde erbij pakt kun je natuurlijk een betere conclusie stellen.
En een rainbow table van 8 tekens voor md5() is redelijk reëel, naar mate het aantal tekens toe neemt stijgt de tijd die het kost natuurlijk ook exponentieël.
Ik hoop dat het nu duidelijk is
Dus:
tbl
table
row
record
db
Zijn bijvoorbeeld de prefixes. In de table seperators staan bijv. punten, kommas en streepjes. En in de table hash staan de hashes.
Bij elke hash gebruiken ze elke mogelijke combinatie van prefixen en seperators.
Klopt dit of vergis ik me?
Ik neem aan dat je als salt toch wel iets als "3al3#$)9jl;'s!" gebruikt. En bovendien is het aantal sites dat nogsteeds alleen md5 gebruikt best groot.
1 letter kleine letter = 26 mogelijkheden
2 letter kleine letters = 26*26 mogelijkheden
Als je dus ook nog alle rare tekens gaat include en cijfers, hoofdletters dan neemt de toename ook toe. Als je dan ook nog geen traag algeritme met meerdere passes gebruikt (bcrypt) dan kun je nagaan dat je bruteforcen vrijwel onmogelijk maakt voor nu, maar ook voor de komende ... jaar :)
Stel je voor je hebt een grid van 10 bij 10. Hier staan een aantal obstakels in. Nu wil je dat een object of persoon van punt 1,2 naar 7,6 gaat bewegen. Dit moet je dus berekenen en dat doe je met behulp van een algoritme. (bijvoorbeeld A*)
Het is dus een soort functie of een set van instructies die iets doet. Het berekenen van een hash, gaat ook met behulp van een algoritme.
Het is een beetje lastig te omschrijven, het is in principe dus een aantal instructies om een bepaalde berekening te doen.
En bcrypt is eigenlijk dus een hashing algoritme.
Smur f op 08/11/2011 13:48:39:
Als je dan ook nog geen traag algeritme met meerdere passes gebruikt (bcrypt) dan kun je nagaan dat je bruteforcen vrijwel onmogelijk maakt voor nu, maar ook voor de komende ... jaar :)
Dan zou ik toch echt wél een traag algoritme gebruiken samen met pbkdf2.
Smur f op 08/11/2011 14:29:18:
Hmm hoe kan ik dat het beste omschrijving, misschien een paar voorbeelden:
Stel je voor je hebt een grid van 10 bij 10. Hier staan een aantal obstakels in. Nu wil je dat een object of persoon van punt 1,2 naar 7,6 gaat bewegen. Dit moet je dus berekenen en dat doe je met behulp van een algoritme. (bijvoorbeeld A*)
Het is dus een soort functie of een set van instructies die iets doet. Het berekenen van een hash, gaat ook met behulp van een algoritme.
Het is een beetje lastig te omschrijven, het is in principe dus een aantal instructies om een bepaalde berekening te doen.
En bcrypt is eigenlijk dus een hashing algoritme.
Stel je voor je hebt een grid van 10 bij 10. Hier staan een aantal obstakels in. Nu wil je dat een object of persoon van punt 1,2 naar 7,6 gaat bewegen. Dit moet je dus berekenen en dat doe je met behulp van een algoritme. (bijvoorbeeld A*)
Het is dus een soort functie of een set van instructies die iets doet. Het berekenen van een hash, gaat ook met behulp van een algoritme.
Het is een beetje lastig te omschrijven, het is in principe dus een aantal instructies om een bepaalde berekening te doen.
En bcrypt is eigenlijk dus een hashing algoritme.
huh? :-/