MD5 vs Blowfish

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Front-end Developer vue.js node.js SaaS

Dit ga je doen Het ontwikkelen van nieuwe features die bijdragen aan de groei van de klanten van de organisatie; Je denkt mee over nieuwe innovaties, features en verbeteringen in de applicatiearchitectuur; Je draagt bij aan de continue ontwikkeling van jouw team doordat je elke dag streeft naar het verbeteren van jouw eigen prestaties; Je neemt actief deel aan Scrum meetings en de Frontend Guild. Hier ga je werken Voor een snel groeiend bedrijf de regio Nieuw Vennep zijn wij opzoek naar een ervaren Front-end Developer. De organisatie is actief in de e-commercebranche en ontzorgt haar klanten middels een SaaS-platform.

Bekijk vacature »

.NET Software Developer

Dit ga je doen Als .NET Software Developer zul jij je voornamelijk bezig houden met: Het van scratch af aan bouwen van applicaties (.NET, C#, Bootstrap, KnockoutJs en WebAPI2); Het testen van jouw code d.m.v. het uitvoeren van unittesten; Het oplossen van bugs in de code; Het onderhouden van contact met collega's betreffende de door jouw ontwikkelde applicaties; Het verbeteren en doorontwikkelen van maatwerkapplicaties. Hier ga je werken Jij gaat aan de slag als .NET Software Developer en gaat je focussen op het bedenken, ontwikkelen en testen van maatwerkapplicaties in voornamelijk C#. Dit ga je doen bij een grote, internationale

Bekijk vacature »

Software Programmeur

Functie omschrijving Voor een informele club in omgeving Delft zijn wij op zoek naar versterking. Ben jij op zoek naar een nieuwe uitdaging als Software Programmeur lees dan snel verder! Als ontwikkelaar kom je terecht op een afdeling van 6 medewerkers. Werkzaamheden Programmeur Je bent bezig met het ontwikkelen van software en webapplicaties. Je kunt technische klussen uitvoeren op locatie. Je onderhoudt contact met de projectleider om er zeker van te zijn dat een project goed verloopt. Je zult klanten ondersteunen. Verder zul je technische ontwerpen en gebruikersdocumentaties schrijven en deze onderhouden. Er wordt voornamelijk gewerkt met PHP, Java en

Bekijk vacature »

Front-end developer (Medior/Senior)

Functie Het front-end team bestaat momenteel uit 4 collega’s en is hard aan het groeien! Samen leveren jullie een essentiële bijdrage aan de applicaties die ze voor hun klanten realiseren. Je werkt in het front-end team samen met de back-end teams en product owners om te zorgen dat de applicaties een fijne gebruikerservaring opleveren. Jouw expertise zorgt ervoor dat de juiste keuzes gemaakt worden qua techniek en ontwerp, van back-end tot aan gebruiker. In samenspraak met je team bepalen jullie de beste keuze voor techniek. Ook is er altijd ruimte om nieuwe technieken te ontdekken. Eisen • Je hebt gedegen

Bekijk vacature »

Laravel / PHP developer gezocht!

Functie omschrijving Wij zijn op zoek naar een Laravel PHP Developer voor een leuk bedrijf in de omgeving van Amsterdam! Je zult je bezig houden met de volgende werkzaamheden: Je gaat aan de hand van de wensen van klanten software ontwikkelen; Je bent bij het gehele proces betrokken; van A tot Z; Je hebt na de oplevering contact met de klant wanneer zij problemen ervaren; Je denkt mee over het verbeteren van de werkprocessen; Je denkt mee over softwareoplossingen; Je speelt in op de behoefte van de klant; Je houdt je bezig met het verbeteren, aanpassen en vernieuwen van de

Bekijk vacature »

Robot Programmeur

In het kort Drie redenen waarom deze vacature uniek is! Programmeren van zelflerende robots Werken op kantoor en testen in de bedrijfshal Je krijgt verantwoordelijkheid, vrijheid en je mag werken naar eigen inzicht De organisatie Hier ga je aan de slag Een bedrijf dat innovatieve robottoepassingen ontwerpt en bouwt voor onder andere de staal industrie, energie- bouw- en agrarische sector. De robots die vaak in combinatie met diverse randapparatuur geleverd worden vormen een totaaloplossing voor de klant. Dit zijn klanten over de hele wereld, van België en Duitsland tot China, India, maar ook in Nederland. Projecten waar momenteel aan wordt

Bekijk vacature »

High level C++ QT Developer

Vacature details Vakgebied: Software/IT Opleiding: Senior Werklocatie: Eindhoven Vacature ID: 13486 Introductie Would you like to be involved in every aspect of software development for our exceptional products, from specification and design to testing and integration? If you're passionate about software development and eager to apply your programming skills to create customer-focused deliverables, then this is the perfect chance for you to expand your expertise. You can become a member of our Machine Control department's data-driven development team, where you'll design and build software solutions that optimize machine productivity. As a senior software design engineer, you'll participate in all phases

Bekijk vacature »

Medior C# Developer

Samen met het development team zorg je ervoor dat alle systemen achter de schermen vlekkeloos werken. Wat doe je als Medior C# Developer bij Coolblue? Als C# developer doe je regelmatig mee aan brainstormsessies over user experience, data en task flow met de UX Designer, Product Owner en Data Scientist in je team. Daarnaast schrijf je op zichzelf staande, consistente en testbare code die goed onderhoudbaar en toekomstbestendig is. Ook C# Developer worden bij Coolblue? Lees hieronder of het bij je past. Dit vind je leuk om te doen Werken met verschillende soorten data-opslag, zoals Oracle of AWS. Problemen oplossen

Bekijk vacature »

.NET developer

Functie As a .NET developer you work together in a multidisciplinary development team with 1-2 Senior .NET developers, two front-end developers, Data Scientists and one UX designer. As a team you work on developing a Cloud based application and making this application more stable. Unit testing will also become very important in your new position. Together with the Senior .NET developer you will be responsible for developing the API. You work with a lot of data and occasionally there will also be data issues and some queries will have to be run. This means that you will work a lot

Bekijk vacature »

Software Programmeur PHP

Functie Ben jij op zoek naar een nieuwe uitdaging als PHP developer en zoek je een leuke platte organisatie? Lees dan snel verder! Voor een opdrachtgever in omgeving Capelle aan den IJssel dat zich gespecialiseerd heeft in het realiseren van veilige netwerkverbindingen zijn wij op zoek naar een leuke software developer ter versterking van het huidige team. Hoe kan jouw dag er straks uitzien? Je gaat software en webapplicaties ontwikkelen met behulp van de talen PHP, JAVA en Node.js. Je gaat technische klussen uitvoeren op locatie bij klanten. Je onderhoudt contact met de projectleider om er zeker van te zijn

Bekijk vacature »

C# .NET Software Developer

Functie omschrijving Ben jij op zoek naar een nieuwe uitdaging binnen software development waar je gaat werken voor een jong en flexibel bedrijf? Lees dan snel verder! Wij zijn op zoek naar een Software Developer met ervaring binnen C# .NET die enthousiast wordt van het aansluiten en begeleiden van (complexe) nieuwe klanten. Verder begeleid je complexe projecten, ben jij iemand die altijd kansen ziet? Dan zoeken wij jou! In deze functie ga jij je bezighouden met: Meedenken in oplossingsrichtingen; Werken aan de architectuur; Het verbeteren van functionaliteiten binnen het dataplatform; Ontwikkelen van nieuwe technologieën. Bedrijfsprofiel Waar ga je aan de

Bekijk vacature »

C# Ontwikkelaar

In het kort Als C# .NET Core ontwikkelaar ga je binnen onze business unit Transport en Logistiek aan de slag complexe maatwerk software voor bedrijf kritische systemen binnen de technische automatisering. Denk bijvoorbeeld een IoT-oplossing voor de logistieke sector waarbij we van ruim 200.000 machines de telemetrie en events verwerken. We zijn actief in de distributielogistiek, havenlogistiek en productielogistiek. Naast C# en .NET Core maken we ook gebruik van Azure technologie. En als trotse Microsoft Gold Partner leren we graag van en met jou. Wil jij jezelf blijven ontwikkelen binnen de technische automatisering met .NET, dan gaan we deze uitdaging

Bekijk vacature »

.NET developer

Functie Als .NET developer start jij in een ontwikkelteam met 15 developers en twee testers. Samen zijn jullie verantwoordelijk voor financiële applicaties met meer dan 50.000 gebruikers. Een deel van het team is verantwoordelijk voor de webapplicaties van deze organisatie. Ook zijn er twee app ontwikkelaars werkzaam in het team die zich focussen op de mobiele applicatie. Als .NET ontwikkelaar ga jij aan de slag met de webapplicaties van deze organisatie. Hierbij maak jij o.a. gebruik van C# .NET, ASP.NET, T-SQL, Angular en TypeScript. De nadruk van jouw functie ligt wel op de backend van de applicatie. Wat jouw functie

Bekijk vacature »

Fasttrack learning & development voor Java dev

Wat je gaat doen: Wij zoeken enthousiaste en ambitieuze junior en medior ontwikkelaars die toe zijn aan de volgende stap in hun carrière. Wij helpen je op je pad naar senior ontwikkelaar door ons fasttrack learning en development programma. Na een kort en intensief programma ga jij aan de slag bij klanten van DPA. Daarnaast krijg je veel ruimte om je te ontwikkelen als persoon en als specialist. De eerste maand gaan we aan de slag om je certificeringen te behalen waaronder OCP (Oracle Certified Professional). Daarnaast nemen we een deepdive in Spring Boot. Ook laten we je kennismaken met

Bekijk vacature »

.NET Developer C#

Dit ga je doen Als developer nieuwe gave features implementeren; Werken met technieken als C# .NET en (REST) API's webservices; Ontwikkelen van koppelingen middels API's; Maken van technische keuzes en beslissingen over de architectuur; Junior collega's coachen; Initiatief nemen voor nieuwe technische mogelijkheden; Je bent een belangrijke schakel - en vindt het leuk - om te schakelen met de business. Hier ga je werken Als C# .NET Developer wordt je verantwoordelijk voor het ontwikkelen van applicaties voor belangrijkste product van deze organisatie. Dit product is een applicatie voor alles omtrent hypotheken. De programmeertaal die je hierbij beheerst is C#. Er

Bekijk vacature »
Gee Bee

Gee Bee

12/01/2017 15:39:57
Quote Anchor link
Heb afgelopen Kerst op diverse fora en zo gelezen dat MD5 zwaar verouderd, achterhaald en ook al 'gekraakt' is en dat het daarom beter is om Blowfish te gebruiken. Nu geloof ik dat meteen als zovelen dat zeggen. Toch is mij wel iets frappants opgevallen waarvan ik graag wil weten hoe anderen, op dit terrein meer deskundigen hier tegenaan kijken.

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
 
PHP hulp

PHP hulp

16/06/2025 04:51:32
 
Ivo P

Ivo P

12/01/2017 16:18:37
Quote Anchor link
ik zou naar php's eigen functies kijken:

http://php.net/manual/en/ref.password.php
 
Ward van der Put
Moderator

Ward van der Put

12/01/2017 16:45:45
Quote Anchor link
Kijk voor achtergrondinformatie ook eens naar de functie crypt():

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.
 
Marlies Maalderink

Marlies Maalderink

13/01/2017 10:18:43
Quote Anchor link
Informatie die gehashed is kan nooit meer terug veranderd worden, ook al weet de hacker welke encryptie er is gebruikt. Dus het maakt niet zoveel uit of een hacker zo kan zien of de data met MD5 of met bcrypt is gehashed.

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.
 
Gee Bee

Gee Bee

13/01/2017 10:30:26
Quote Anchor link
Hoi Marlies,

Dank voor je antwoord! Daar heb ik iets aan!

Groet, Gee
 
Ivo P

Ivo P

13/01/2017 10:50:57
Quote Anchor link
"Iedere hash moet uniek zijn"

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
 
Thomas van den Heuvel

Thomas van den Heuvel

13/01/2017 14:55:08
Quote Anchor link
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?
 
Marlies Maalderink

Marlies Maalderink

13/01/2017 15:13:04
Quote Anchor link
Thomas van den Heuvel op 13/01/2017 14:55:08:
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

13/01/2017 15:25:26
Quote Anchor link
Dat is mijn punt min of meer: als een default op een gegeven moment wijzigt (of verdwijnt) kan dit functionaliteit breken. Je schrijft sowieso geen code voor de eeuwigheid. En met name security-gerelateerde code, daar zou je bovenop moeten zitten (of zou iig eens in de zoveel tijd gereviewd moeten worden).

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.
 
Ward van der Put
Moderator

Ward van der Put

13/01/2017 15:39:09
Quote Anchor link
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è? ;-)
 
Marlies Maalderink

Marlies Maalderink

13/01/2017 17:39:54
Quote Anchor link
Ik snap jullie punt en het klinkt logisch. Ik gebruik default omdat dat in de documentatie aangeraden wordt maar begin nu te twijfelen of dat dan wel zo handig is...

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...
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/01/2017 21:01:13
Quote Anchor link
>> 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.


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?
 
Thomas van den Heuvel

Thomas van den Heuvel

13/01/2017 23:41:16
Quote Anchor link
Je telt het aantal pogingen per gebruiker lijkt mij (los van IP)? Ik wilde daarmee alleen maar laten zien dat wanneer je meerdere lagen aanbrengt (beperkt aantal pogingen per tijdseenheid per gebruiker) dat het daardoor ook al een aanzienlijk stuk moeilijker wordt om dingen te kraken. Je kunt dan namelijk simpelweg niet meer bruteforcen.

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.
 
Marlies Maalderink

Marlies Maalderink

23/01/2017 15:05:22
Quote Anchor link
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...
 
Ward van der Put
Moderator

Ward van der Put

24/01/2017 07:19:43
Quote Anchor link
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...

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)
PHP script in nieuw venster Selecteer het PHP script
1
'$2y$' . $work_factor . '$' . $salt . '$'

En bij SHA-512:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
'$6$rounds=' . $work_factor . '$' . $salt . '$'
 
Marlies Maalderink

Marlies Maalderink

24/01/2017 10:23:29
Quote Anchor link
Ward van der Put op 24/01/2017 07:19:43:

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.