Tenzij je een salt gebruikt, dan heeft niemand wat aan een rainbow-table.
SHA1 raakt tegenwoordig steeds vaker in opmars...
Dat is waar, maar met de steeds sneller wordende hardware zal het nogsteeds wel mogelijk zijn om de salt te achterhalen, dan zou je al haast een aparte salt per gebruiker moeten gebruiken wat natuurlijk ook een mogelijkheid blijft.
Het is natuurlijk ook hoe moeilijk je het ze wilt maken en hoe ver je zelf wilt gaan.
Dat is waar, maar met de steeds sneller wordende hardware zal het nogsteeds wel mogelijk zijn om de salt te achterhalen, dan zou je al haast een aparte salt per gebruiker moeten gebruiken wat natuurlijk ook een mogelijkheid blijft.
Als je een salt+pass combinatie gebruikt die bij bruteforcen het eerst voorkomende hash genereerd (ook wel, een kortere combinatie die dezelfde hash genereerd komt niet voor) en je ziet dit bijvoorbeeld twee maal gebeuren, zou je een vergelijking kunnen zien en dus de salt kunnen achterhalen (hoe meer je er achterhaalt hoe makkelijker dat wordt natuurlijk).
Als jij dus altijd pass+salt doet, dan zul je dus een rainbow table kunnen maken met die salt.
Maar hoe langer je salt is, hoe groter de kans is op een colission dus hoe lastiger het wordt om het orgineel te achterhalen. Dit komt omdat er oneindig invoer mogelijkheden zijn en een beperkt aantal uitvoer mogelijkheden.
Met een salt ga je dus zorgen dat ze meer invoer mogelijkheden moeten proberen voordat ze het kunnen achterhalen en zorg je dat de kans dat, ALS ze een gelijke hash hebben gevonden en de invoer verschillend is, hoger wordt.
Het punt is dus, mogen ze dus de moeite nemen om een rainbow table te maken voor je hashes van gesalte wachtwoorden, ze dus bij de kortste wachtwoorden mogelijk al de salt kunnen achterhalen. Als dit zou gebeuren wordt het proces van de andere achterhalen gigantisch verkort, aangezien je het aantal mogelijkheden gigantisch gaat verlagen.
Dus in principe is het zo dat je eigenlijk verschillende salts wilt gebruiken, die lang zijn, het is namelijk niet zo erg dat ze een invoer vinden die dezelfde hash genereerd aangezien ze daar niets mee kunnen.
Het voordeel van crypt() (met behulp van bcrypt) is dus dat het genereren van rainbow tables dus gigantisch veel trager is aangezien bcrypt een algoritme is die traag is. Voor jou maakt een extra 10 ms niet uit, voor een bruteforcer wel :)
tl;dr:
hashes zijn handig als je ze goed toe past (het proces van het genereren van de juiste hash traag maken)
Wooow... dankje voor je uitleg, maar ik snap de 1e alinea nog steeds niet. Stel we hebben 2 wachtwoorden: boom en boek. Ik salt ze tot bla_boom en bla_boek en gooi er een MD5 overheen. Dan krijg je toch 2 totaal verschillende strings van 32 tekens:
c6a5c55dda637108d317d11024b96436 en bdfb4aa7cc60785d05f9792835818eb8
Daar kun je toch nooit een salt uithalen???
Nog een simpel voorbeeld: je MD5't de letter a, dan krijg je:
0cc175b9c0f1b6a831c399e269772661
en nu aa, dan krijg je:
4124bc0a9335c27f086f24ba207a4912
Het punt is, dat je dus met bruteforcen gewoon alle mogelijkheden af gaat en wanneer je bij 'bla_boom' komt, zie je dat de hashes overeen komen. Hetzelfde bij 'bla_boek'
Je weet nu van 2 gebruikers het "wachtwoord":
bla_boom
bla_boek
Hmm, beide bla_ ervoor, zou dit de salt zijn? Grote kans van wel. Dus in plaats dat wij nu gaan bruteforcen met alle mogelijkheden beperken we dit dus tot "bla_" + alle mogelijkheden daar achter en ben je dus het effect van de salt zo ongeveer kwijt.
Als we nu een langere salt gebruiken, is er dus een grotere kans dat er een invoer is VOOR het echte wachtwoord die dezelfde hash genereerd.
Als voorbeeld hier van gebruiken we even een hash van 6 tegen maximaal (md5 heeft er 32)
Stel je voor we hebben asdfasdfasdfasdf_blaat, die geeft (bv) 123456 als hash.
We zien dus, het aantal tekens van het gehaste wachtwoord meer is dan de hash zelf is. Dus er is een grote kans dat als we gaan bruteforcen, we meerdere keren dezelfde hash krijgen met verschillende invoer. Dat maakt het achterhalen al weer een stukje lastiger.
Sorry, ik snap echt niet hoe je dit bedoelt. Laten we ons even focussen op de 1e 2 alinea's.
Jij zegt "Het punt is, dat je dus met bruteforcen gewoon alle mogelijkheden af gaat en wanneer je bij 'bla_boom' komt, zie je dat de hashes overeen komen."
Ja, dat klopt... maar dit is toch helemaal niet reëel? Ten eerste begint het er al mee dat iemand niet weet op welke manier een wachtwoord is gecodeerd. Dan moet ie vervolgens denken... iemand zal vast als wachtwoord "boom" hebben, en dan ga je vervolgens "boom" bruteforcen met allerlei prefixes. En dan moet tussen die prefixes toevallig ook nog eens "bla_" staan. En in werkelijkheid gebruik je natuurlijk een of andere rare salt zoals "dfkj34s". Nou, ik denk niet dat iemand dat tussen z'n prefixes heeft staan. Gooi er dan ook nog een pepper bij... en dan ga je het toch nooit kunnen kraken :-s
