MD5 vs Blowfish
Als ik een serie wachtwoorden met MD5 hash krijg ik daar per wachtwoord een totaal verschillende string uit. Als ik dezelfde serie wachtwoorden met Blowfisch hash ( gebruik hiervoor password_hash('wachtwoord',PASSWORD_BCRYPT) waarbij 'wachtwoord' natuurlijk niet het letterlijk wachtwoord is ) krijg ik per wachtwoord een string waarvan de eerste 7 karakters hetzelfde is!!!
Nu heb ik uit de documentatie begrepen dat dit te maken heeft met de 'salt' binnen de 'hash' ... of zoiets. De vraag die ik nu probeer te stellen is of zo'n hash nou juist niet gevoeliger is? Als iemand - met een beetje verstand van zaken - een tabel opent en daarin een serie gehaste wachtwoorden met dezelfde 7 beginkarakters ziet, kan die dat gemakkelijk(er) als een 'Blowfish' hash herkennen en dan heeft die stap 1 naar het kraken van die hash al gezet. MD5 hashes zijn, juist door de volledige random karakters die het genereert, op dit punt minder 'herkenbaar'.
Nogmaals, ik ben op dit terrein een volledige novice en dus bij voorbaat 'sorry' als ik een - voor het op dit forum gebruikelijke niveau - domme vraag stel. Ben gewoon zeer benieuwd en nieuwsgierig.
Groet,
Gerard
Gewijzigd op 12/01/2017 15:41:50 door Gee Bee
http://php.net/crypt
Hier wordt kort maar krachtig uitgelegd hoe de strings die worden toegevoegd voor de salt zijn opgebouwd. Dat die strings vervolgens voor het versleutelde wachtwoord worden geplakt (waardoor de eerste tekens hetzelfde zijn), is geen risico.
Iedere hash moet uniek zijn. Daarom wordt MD5 niet meer gebruikt, MD5 maakt soms van verschillende invoer dezelfde hash. Voor wachtwoorden in een database maakt dat niet zoveel uit maar dat is wel waarom hij 'gekraakt' is.
Er zijn 2 veel gebruikte manieren voor een hacker om wachtwoorden uit een database te cracken. In het verleden werd er veel gebruikt gemaakt van zgn 'rainbow lists', lijsten met gigantische hoeveelheden mogelijke wachtwoorden, die allemaal gehashed waren, waarbij dan de wachtwoorden in de database vergeleken werden met de wachtwoorden op de lijst en er een match gevonden kon worden. (er is altijd wel iemand die niet zo'n sterk wachtwoord gebruikt)
Toen kwam salt en was het gebruik van deze lijsten niet meer zinvol, immers, alle wachtwoorden die je maar kunt bedenken worden nu gecombineerd met een salt en dán gehashd.
Daarom is nu denk ik de beste mogelijkheid voor een hacker een 'brute force' attack, in het inlogscherm oneindig veel wachtwoorden invoeren, niet met hand natuurlijk ;)
Hierbij is er een belangerijk verschil tussen MD5, crypt en bcrypt. MD5 is razendsnel. Binnen een seconde kan de hacker miljoenen wachtwoorden invoeren. ook crypt is redelijk snel. bcrypt daarintegen is erg langzaam, ongeveer een seconde per invoer. (bovendien kun je als je password_hash gebruikt met $cost de tijdsduur nog aanpassen). Hierdoor duurt meestal het dagen of weken in plaats van uren om een wachtwoord dat matched te vinden en is de kans groot dat de hacker er bij voorbaat al niet aan begint.
Hoe het precies zit met die zelfde tekens aan het begin van de hash weet ik niet, het zal met de salt te maken hebben maar het zal niet zo zijn dat die tekens de salt zijn en de rest het wachtwoord want zo werkt een hash niet en bovendien zou dat het hele nut van de salt weg zijn...
Overigens kun je beter password_hash('wachtwoord',PASSWORD_DEFAULT)gebruiken. Momenteel gebruiken beide opties Bcrypt, maar PASSWORD_BCRYPT zal altijd bcrypt blijven gebruiken, en default kan in de toekomst een nieuwe, betere, encryptie methode gaan gebruiken als die er zou komen. Dus met default heb je altijd het beste.
Dank voor je antwoord! Daar heb ik iets aan!
Groet, Gee
Dat gaat nooit lukken. Bijvoorbeeld een md5 hash is altijd 32 tekens lang. (en dan ook nog beperkt tot 0-9A-F)
Wat voor "breedte" je een hash ook geeft: er zullen altijd meer strings zijn dan de mogelijke hashes.
Om het even in vatbare begrippen te gooien: stel dat ik een hashing bedenk die alleen op getallen werkt en dan ook een getal oplevert. Die uitkomst is beperkt tot 2 tekens (cijfers).
Dat betekent dan dat ik dus maar 100 uitkomsten heb (00-99)
Maar en zijn veel meer invoeren te bedenken. Bijvoorbeeld de getallen 100-1000. Dat betekent dus inderdaad dat er de nodige dubbelen voor kunnen komen in mijn beperkte voorbeeld.
Maar dat principe gaat ook op voor een hash van 3, 4 of 32 karakters en zelfs als je naast cijfers ook nog andere tekens in de hash laat voorkomen.
Nu schijn je voor het vinden van dubbele md5's al een heel grote string te moeten hebben. Maar in principe kun je ook heel de inhoud van de Dikke Van Dale als invoer in md5() stoppen. Daar zal ook een string van 32 tekens uit komen.
Maar probleem lijken vooral de rainbow tables te zijn. En dan met name ook door het ontbreken van de salt in veel gevallen.
Wat niet wegneemt dat je md5 intussen beter links kunt laten liggen.
NB:
Ik heb wel eens de indruk dat er gedacht wordt dat elke site die de passwords alleen met md5 gehasht opslaat nu direct gehackt kan worden. Daarvoor heb je wel eerst toegang tot de lijst met gehashte passwords nodig
Quote:
MD5 maakt soms van verschillende invoer dezelfde hash.
Dit is inherent aan hashing, en niet zozeer van MD5. Bij MD5 treden er echter meer "collisions" op (verschillende soorten invoer die leiden tot dezelfde hash) geloof ik, waardoor de eerdergenoemde rainbow tables inzetbaar zijn voor het kraken.
Quote:
Overigens kun je beter password_hash('wachtwoord',PASSWORD_DEFAULT)gebruiken
Is dit zo? Bij dit soort zaken moet je niets aan het toeval overlaten lijkt mij, dus mogelijk is het beter om expliciet in te stellen wat je gebruikt, anders valt PASSWORD_DEFAULT mogelijk terug op een snellere/makkelijker te bruteforcen methode. Was dit niet precies dezelfde wijze waarop een lek in HTTPS werd uitgebuit? Door manipulatie werd teruggevallen op standaard encryptie (dit is overigens niet hetzelfde als hashing) waardoor het mogelijk was om dataverkeer te ontcijferen.
Daarnaast hebben verschillende algoritmes mogelijk verschillende formaten (die een verschillende opslag of controle vereisen), tenzij dit helemaal gestandaardiseerd is (maar dan zul je dus deze standaardisatie ook in je wachtwoord-opslag moeten verwerken)? Maar dan kun je je afvragen waarom die functie een algoritme-parameter heeft, als je toch altijd dezelfde gebruikt.
Los van dit alles: bij veiligheid is het beter om met lagen te werken, en niet alles te gooien op één "(first and last) line of defense".
Quote:
Wat niet wegneemt dat je md5 intussen beter links kunt laten liggen.
Beschouw het volgende scenario: je gebruikt een modern hashing algoritme (post md5/sha1) maar je bouwt geen enkele beveiliging in voor een gelimiteerd aantal inlogpogingen noch functionaliteit voor het volgen van inlogpogingen. Het is dan nog steeds mogelijk, al duurt het wat langer, om te bruteforcen.
Stel hier tegenover een loginsysteem met md5 die maximaal X onjuiste logins accepteert per tijdseenheid Y en die bijhoudt waar deze vandaan komen waarbij tevens wordt verwacht dat het wachtwoord aan zekere kenmerken voldoet en eens in de zoveel tijd vernieuwd moet worden.
Welk systeem is veiliger?
Thomas van den Heuvel op 13/01/2017 14:55:08:
Is dit zo? Bij dit soort zaken moet je niets aan het toeval overlaten lijkt mij, dus mogelijk is het beter om expliciet in te stellen wat je gebruikt, anders valt PASSWORD_DEFAULT mogelijk terug op een snellere/makkelijker te bruteforcen methode. Was dit niet precies dezelfde wijze waarop een lek in HTTPS werd uitgebuit? Door manipulatie werd teruggevallen op standaard encryptie (dit is overigens niet hetzelfde als hashing) waardoor het mogelijk was om dataverkeer te ontcijferen.
Quote:
Overigens kun je beter password_hash('wachtwoord',PASSWORD_DEFAULT)gebruiken
Is dit zo? Bij dit soort zaken moet je niets aan het toeval overlaten lijkt mij, dus mogelijk is het beter om expliciet in te stellen wat je gebruikt, anders valt PASSWORD_DEFAULT mogelijk terug op een snellere/makkelijker te bruteforcen methode. Was dit niet precies dezelfde wijze waarop een lek in HTTPS werd uitgebuit? Door manipulatie werd teruggevallen op standaard encryptie (dit is overigens niet hetzelfde als hashing) waardoor het mogelijk was om dataverkeer te ontcijferen.
Dit staat letterlijk in de php documentatie. default en bcrypt gebruiken nu bcrypt. default kan vervangen worden, in de toekomst, als er een veiligere methode zou komen die ook al een test periode heeft doorstaan. Maar snap jouw punt ook wel, je moet maar afwachten of dat dan op de lange termijn ook echt beter is.
Misschien is er wel iets voor te zeggen om ergens instelbaar te maken welk algoritme gebruikt wordt. Maar deze instelling is dan een "hoofdschakelaar" waarmee de creatie, opslag en verificatie van wachtwoorden centraal omgaat.
Marlies Maalderink op 13/01/2017 15:13:04:
default en bcrypt gebruiken nu bcrypt. default kan vervangen worden, in de toekomst, als er een veiligere methode zou komen die ook al een test periode heeft doorstaan.
Daarom kun je juist beter niet "automagisch" de default gebruiken: als de default verandert, loop je het risico dat in één keer alle met de vorige default versleutelde wachtwoorden ongeldig zijn. Dan zit je na een PHP-update met een onbruikbare database. Of omgekeerd: je kunt PHP niet updaten omdat anders je database onbruikbaar wordt.
Je kunt beter de cost c.q. work factor opkrikken, zodat de hardware 5 seconden staat te stampen op één wachtwoord. Dat is namelijk niet te brute forcen als de tabel met wachtwoorden in verkeerde handen valt (en iemand dus zeeën van tijd heeft om er op een eigen machine op los te gaan).
Verder kun je, zoals Thomas zegt, beter exact vastleggen welk algoritme je met welke instellingen gebruikt. Dan kun je namelijk bij een update of na een inbraak gericht die wachtwoorden updaten. En standaard gebeurt dat al bij een sterke encryptie: aan het begin van de resulterende string worden tussen $ algoritme, work factor en salt toegevoegd. Dat is niet voor niets, hè? ;-)
Toevoeging op 13/01/2017 17:48:04:
Als aanvulling, ik heb net de documentatie doorgelezen maar het staat er ook helemaal niet. Weet ook even niet hoe ik er dan bij kwam, mijn excuses.. Zal wel in de war zijn geweest...
Dit is ook een leuke discussie. De functionaliteit van een login is om van een anonieme gebruiker een bekende gebruiker te maken. Even aannemende dat je een login hebt met gebruikersnaam + wachtwoord kan een hacker telkens van gebruikersnaam en wachtwoord wisselen. Gebuikt hij hier ook nog een aantal verschillende proxies dan is de mix compleet. Hoe ga je deze brute force methode tegenhouden dan?
Ik bedoel:
- Je kunt je login helemaal op slot zetten maar dan kan niemand meer binnen komen
- je kunt bij meerdere logins vanaf 1 en dezelfde ip blokkeren maar het risico bestaat dat je hiermee een bedrijf met 5000 werknemers de toegang ontzegt.
- Je kunt als de hacker al een bestaande gebruikersnaam gebruikt natuurlijk deze gebruikersnaam blokkeren maar zelfs dan kun je een boze reactie verwachten.
Hoe gaan jullie daar mee om dan?
Je kunt het voorbeeld binnen een bedrijf ook omdraaien: je zou ook een whitelist van IP's kunnen introduceren via welke je enkel kunt inloggen. Dan hoef je de hacker ook niet ver te zoeken :].
En als je server zodanig onder vuur ligt dan wordt het tijd voor andere oplossingen.
Gee Bee op 12/01/2017 15:39:57:
Als ik een serie wachtwoorden met MD5 hash krijg ik daar per wachtwoord een totaal verschillende string uit. Als ik dezelfde serie wachtwoorden met Blowfisch hash ( gebruik hiervoor password_hash('wachtwoord',PASSWORD_BCRYPT) waarbij 'wachtwoord' natuurlijk niet het letterlijk wachtwoord is ) krijg ik per wachtwoord een string waarvan de eerste 7 karakters hetzelfde is!!!
Het is geen nieuw topic meer maar toevallig las ik vanmiddag hoe het zit met de eerste 7 characters van de bcrypt hash, voor het geval iemand zich het toch nog afvraagt...
Het heeft niets met de salt te maken maar met de hash methode zelf.
Bcrypt hashes beginnen altijd met $2y$1(nog 1 cijfer)
waarbij $2y staat voor bcrypt, $10 (of $11 of $12) voor de cost. Dan komt pas de salt. Het enige wat de mogelijke hacker hier dus uit kan afleiden is de hash methode en de cost die is ingesteld, maar niet wat de salt is...
Marlies Maalderink op 23/01/2017 15:05:22:
Bcrypt hashes beginnen altijd met $2y$1(nog 1 cijfer)
waarbij $2y staat voor bcrypt, $10 (of $11 of $12) voor de cost. Dan komt pas de salt. Het enige wat de mogelijke hacker hier dus uit kan afleiden is de hash methode en de cost die is ingesteld, maar niet wat de salt is...
waarbij $2y staat voor bcrypt, $10 (of $11 of $12) voor de cost. Dan komt pas de salt. Het enige wat de mogelijke hacker hier dus uit kan afleiden is de hash methode en de cost die is ingesteld, maar niet wat de salt is...
Wel de salt maar niet de salt? ¯\_(?)_/¯
Een hacker kán de salt zien, want die staat achteraan. Bij Blowfish is de string namelijk:
Code (php)
1
'$2y$' . $work_factor . '$' . $salt . '$'
En bij SHA-512:
Code (php)
1
'$6$rounds=' . $work_factor . '$' . $salt . '$'
Ward van der Put op 24/01/2017 07:19:43:
Wel de salt maar niet de salt? ¯\_(?)_/¯
Wel de salt maar niet de salt? ¯\_(?)_/¯
Ja, beetje onduidelijk gefomuleerd ;) Wat ik bedoelde te zeggen is dat de salt niet de eerste 7 identieke tekens van de hash is, waar de topic starter bang voor was.