salt
Ward, ik lees her en der dat md5 en sha1 wordt afgeraden vanwege de kans op collisions. Het lijkt me dat het dus wel degelijk iets uitmaakt. Nee, natuurlijk is de kans dat er een collision plaatsvindt vrijwel nihil. Maar de kans bestaat wel. Dus als je dat vantevoren al weet, waarom dan niet een beter alternatief kiezen?
Probeer te begrijpen wat je (verkeerd) doet: de zwakke plek zit helemaal niet in de algoritmen MD5 en SHA-1, maar achter hoe jij ze zelf wilt inzetten.
Zelfs als je het sterkste algoritme verkeerd gebruikt, los je die fout niet op. Vragen naar het sterkste algoritme heeft daarom ook geen zin.
Alleen als ik ga hashen wil ik niet dat er collision plaatsvindt. Daarom zoek ik de beste optie.
Waarschijnlijk is sha512 de beste optie. Alleen die creëert een belachelijk lange string. Dus ik ben benieuwd of sha 256 ook een goede optie is, of dat je dan een grotere kans op collision hebt.
Als je een exacte match op de string $_SERVER['HTTP_USER_AGENT'] gebruikt, heb je nooit een collision. Door juist niet de hash te gebruiken, maar de oorspronkelijke string, heb je (a) een exacte match en (b) niet de overhead van minstens twee keer een hash moeten berekenen.
Wat je ook zou kunnen zeggen: je veroorzaakt de potentiële collision nu zelf door niet de strings exact te matchen maar via een omweg eerst twee keer een hash te genereren en daarna de hashes te vergelijken.
Je lost een beveilingsprobleem waarvoor dit geen oplossing is dus op met een oplossing die leidt onder een beveiligingsprobleem dat je zelf inbouwt....
Maar om je toch een antwoord te geven: in theorie is een langere sleutel beter omdat er meer combinaties mogelijk zijn, dus de 512-bits variant van SHA-2 (sha512).
Ja, daar heb je ook een goed punt. Is inderdaad iets om over na te denken.
Ik heb die truc met het hashen eens zien toepassen door programmeurs die NL teksten op hun website hadden staan, en de hashes van die teksten gebruikten voor vertalingen. Dus zoiets als dit:
Als de taal stond ingesteld op NL returnde die translate functie de tekst, maar als de taal bijv. op EN stond, dan werd de tekst gehashed en werd aan de hand van die hash de EN tekst in de database opgehaald.
Anyhow. Waarom ik een hash wil gebruiken omdat die altijd dezelfde lengte heeft en dat is handig met opslaan (bijv. in de database). Daarnaast was de bedoeling dat de hash korter zou zijn dan de originele string. Als ik sha512 gebruik is dit echter niet altijd het geval. Soms is de hash dan langer. Dus zodoende vroeg ik me af of ik ook sha256 kan gebruiken. Die is namelijk wel altijd korter dan de sha512 hash. Echter vraag ik me af in hoeverre dat erg is. Het schijnt dat er nog nooit collisions zijn voorgekomen met sha256 en sha512. Maar wat is dan wel het verschil tussen deze beide algoritmes? Als collisions onmogelijk zijn, wat is dan nog het voordeel van sha512 ten opzichte van sha256 ???
Hehe, lol...
Suggereer jij hiermee dat beiden net zo veilig zijn, en sha512 geen enkele maar dan ook geen enkele meerwaarde heeft ten opzichte van sha256?
substr(hash('sha512', 'iets'), 256) is voor we weten net zo veilig als hash('sha256', 'iets')
bron: http://crypto.stackexchange.com/questions/3153/sha-256-vs-any-256-bits-of-sha-512-which-is-more-secure
Beide slagen er (waarschijnlijk) in om kwaadwillende de komen paar decenia bezig te houden om een collision te vinden die ze zouden kunnen misbruiken.
Alleen helaas niet als je een sessie wilt beveiligen door de hash van $_SERVER['HTTP_USER_AGENT'] te gebruiken...
Als de input voorspelbaar is, is de hash ook voorspelbaar. Dat is nu juist het hele eiereneten bij een reproduceerbare hash! Wat is hier nu zo moeilijk van te begrijpen?
Ozzie PHP op 31/03/2014 17:49:21:
en sha512 geen enkele maar dan ook geen enkele meerwaarde heeft ten opzichte van sha256?
Performance-technisch heeft SHA-512 wel een meerwaarde. Wanneer je berichten van meer dan 8 bytes gaat hashen, is SHA-512 sneller. Dat kan oplopen tot 53% (bij berichten van 512 bytes).
Als je dan toch niet secure werkt door $_SERVER['HTTP_USER_AGENT'] te hashen, kun je dat maar beter zo snel mogelijk doen. ;-)
De theoretische veiligheid van een algoritme en de veiligheid van iets waarin je dat algoritme gebruikt zijn twee verschillende dingen.
Hoe weet ik of mijn bericht groter is dan 8 bytes?
>> Als je dan toch niet secure werkt door $_SERVER['HTTP_USER_AGENT'] te hashen, kun je dat maar beter zo snel mogelijk doen. ;-)
Hehe... lol. Hoe kan het eigenlijk dat sha512 sneller is, terwijl het een complexere string oplevert?
>> de input voorspelbaar is, is de hash ook voorspelbaar. Dat is nu juist het hele eiereneten bij een reproduceerbare hash! Wat is hier nu zo moeilijk van te begrijpen?
Wie zegt dat ik je niet begrijp?
Begrijp jij dan wat ik bedoel? Stel jij bent aan het "gokken" met session ids. Jij "raadt" per toeval mijn session id. Omdat je een andere browser hebt, of jouw browser anders is ingesteld, genereer jij een andere hash dan de hash die bij de sessie hoort. Op dat moment wordt meteen de sessie verwijderd.
Wat snap jij daar dan niet aan?
Mijn vraag wat het beste algoritme is met de minste kans op een collision, heeft betrekking op het feit dat niet de browser van de hacker per ongeluk dezelfde hash genereert (terwijl de input anders is) en dus een collision veroorzaakt.
Gewijzigd op 31/03/2014 20:29:49 door Ozzie PHP
Ozzie PHP op 31/03/2014 20:29:03:
Het is geen onafhankelijke kans, maar een afhankelijke kans. Dan werkt statistiek in je nadeel.Begrijp jij dan wat ik bedoel? Stel jij bent aan het "gokken" met session ids. Jij "raadt" per toeval mijn session id. Omdat je een andere browser hebt, of jouw browser anders is ingesteld, genereer jij een andere hash dan de hash die bij de sessie hoort. Op dat moment wordt meteen de sessie verwijderd.
Wat snap jij daar dan niet aan?
Wat snap jij daar dan niet aan?
Als een hacker al zo ver is dat hij de sessie-ID kan raden (of kapen), is hij wel zo slim om de client-headers meteen mee te nemen.
Je gaat steeds maar uit van toeval, maar gaat daarbij voorbij aan het feit dat een aanval juist op het tegendeel berust: toeval uitsluiten. Daar is die salt ook op gebaseerd.
Hacker en crackers raden niet, maar zijn juist heel berekenend.
En waar haalt hij die vandaan?
Klopt, maar dat was mijn vraag niet ;)
Jij zegt dat de hacker de headers van de client van een te kapen sessie kan faken. Ja, dat kan... maar als hij session ids gaat "raden" dan moet hij die headers van te voren al weten. Correct? En hoe gaat hij die van tevoren weten? Niet... hij kan ze hooguit gokken. Snap je wat ik bedoel? Zodra hij inderdaad een sessie te pakken heeft, en hij gebruikt een andere browser, valt hij direct door de mand.
Voor salts geldt dus min of meer hetzelfde als voor fingerprints.
De hacker kan bijvoorbeeld een User-Agent hebben ingesteld op: F\/CK O-/-ie
Daarna laat hij enkele weken tientallen clients braaf surfen met de header: F\/CK O-/-ie
Na verloop van tijd vertrouwen de Ozzie-servers daarom die dankbare gebruikers met de header: F\/CK O-/-ie
Je beveiligt via $_SERVER['HTTP_USER_AGENT'] daarom feitelijk niets.
Sterker nog: je verzwakt de beveiliging door op unieke headers van de user agent te vertrouwen. Een botnet kan zo de F\/CK O-/-ie clients betrouwbaarder laten lijken dan ander clients. Die headers komen namelijk véél vaker voor. En worden dagelijks gebruikt.
Ozzie PHP op 31/03/2014 20:29:03:
>> Performance-technisch heeft SHA-512 wel een meerwaarde. Wanneer je berichten van meer dan 8 bytes gaat hashen, is SHA-512 sneller. Dat kan oplopen tot 53% (bij berichten van 512 bytes).
Hoe weet ik of mijn bericht groter is dan 8 bytes?
Hoe weet ik of mijn bericht groter is dan 8 bytes?
Gewoon, kijken wat je als input aanlevert. Hoeveel tekens zitten er in "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727)"? Zo op het blote oog zijn dat er meer dan 8. ;-)
Quote:
Hoe kan het eigenlijk dat sha512 sneller is, terwijl het een complexere string oplevert?
SHA-256 gebruikt een block size van 32 bits (4 bytes) en SHA-512 gebruikt een blocksize van 64 bits (8 bytes).
Bij dezelfde input zal SHA-256 dus twee keer zoveel blocks hebben om te hashen dan SHA-512. Dat hashen gebeurt door simpele berekeningen op een block uit te voeren, zoals AND, XOR, shift, etc. Een beetje server heeft tegenwoordig een 64-bits processor. Voor 64-bits processors kost een berekening op een 64-bits block evenveel als op een 32-bits block. Bij SHA-256 moeten er twee keer zoveel berekeningen worden uitgevoerd die elk even lang duren als de berekeningen bij SHA-512. Daarom is SHA512 bijna altijd sneller.
Ik heb bijv. als taal nl er tussen staan. Een hacker buiten nl heeft dat niet. Mijn IE browser levert bijv. al een andere hash op dan mijn Firefox browser.
Mijn server slaat de hash enkel in een sessie op. Als gedurende die sessie die hash ineens wijzigt, verwijder ik de complete sessie. Dit is dus iets heel anders dan wat jij zegt.
Deze beveiliging geldt dus slechts gedurende de sessie. Met die hash wordt verder niks gedaan. Snap je wat ik bedoel?
@Willem: oke, duidelijke uitleg!