MD5 vs Blowfish

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Lead Webdeveloper

Als Lead webdeveloper bij KUBUS ben je verantwoordelijk voor het implementatie design van requirements en de software architectuur van de webapplicatie en services van BIMcollab. In je rol als lead developer zoek je als vanzelf op een creatieve manier naar het optimum tussen benodigde implementatie-tijd, de performance van de applicatie en een snelle go-to-market van features, aansluitend bij onze geautomatiseerde test- en release train. Hierbij bewaak je in samenwerking met de andere senior ontwikkelaars in je team de architectuur van de applicatie en adviseer je de product owner over noodzakelijke refactoring om de onderhoudbaarheid van het platform te verbeteren. Ons

Bekijk vacature »

SQL Developer

Functie omschrijving We are looking for a dutch native speaker Jij gaat in deze functie aan de slag met uitdagende projecten en het creëren van maatwerk software, vooral middels SQL. Iedere klant/project is weer anders, maar dat maakt dit bedrijf en de functie erg uniek & uitdagend. Verder heb je de volgende taken: Ontwikkelen en ontwerpen van SQL databases. T-SQL wordt hierbij gebruikt als programmeer laag; Optimalisatie van query's, voor een verbeterde efficiency; Begeleiden van junior developers, mits je dit leuk vindt; Heb je meer interesse in een rol als consultant, dan is dit ook mogelijk. Je heb hier meer

Bekijk vacature »

C++ Ontwikkelaar

Functieomschrijving Ben jij als software ontwikkelaar toe aan een nieuwe uitdaging? Dan zoeken wij jou! Voor het maken van de procesbesturingssoftware gebruiken onze projectteams een in C++ en C# geschreven tool. Dit is een gedistribueerd object framework wat alle kernfuncties biedt voor een procesautomatisering. Verder zullen jouw werkzaamheden o.a. bestaan uit: Ontwerpen, programmeren en testen van product aanpassingen; Analyseren van vragen en wensen van gebruikers en deze vertalen naar een functioneel ontwerp; Inzichtelijk maken van voortgang omtrent softwarewerkzaamheden, o.a. door middel van SCRUM; Continu toetsen van het effect van nieuwe releases op andere tools en processen; Implementeren van nieuwe product

Bekijk vacature »

Junior .NET developer

Functie Als junior .NET developer begint jouw dag na een bak koffie met een stand up. De vorderingen worden tijdens de stand up besproken en de doelen worden opgesteld waar jullie als team in de volgende sprint naartoe gaan werken. Onze backend is geschreven in .NET Core en onze Front-end in Angular. Bij ons ga jij dan ook Fullstack aan de slag. Jij wordt hier opgeleid om zelfstandig te kunnen programmeren en applicaties te kunnen implementeren. Er wordt op projectbasis gewerkt, dit bied leuke uitdagingen omdat elke klant een andere visie heeft over de applicatie die wij maken. Je gaat

Bekijk vacature »

Database ontwikkelaar

Functieomschrijving Wil jij aan gave logistieke softwareprojecten werken en bij een uniek softwarebedrijf in de regio van Tilburg? Wacht niet langer en reageer snel op deze vacature. Als Database ontwikkelaar ga je aan de slag het schrijven van stored procedures en verder uitbouwen van de SQL database. Je werkt in een database team, met allemaal mensen die energie krijgen van software en techniek. Verder krijg je als taak: Optimaliseren en uitbouwen van de MS SQL databases die gebruikt worden; Optimaliseren van query's, waardoor er efficiënter gewerkt kan worden; Je werkt met de technieken T-SQL of PL/SQL; Bij interesse kan je

Bekijk vacature »

Back End Developer

Als Back End developer bij KUBUS houd je je bezig met het ontwikkelen van de (web)applicatie en services van BIMcollab. Je hebt een focus op de back end van onze software, daarvoor werken wij hoofdzakelijk met C# en .NET. Wij hanteren een full-stack benadering, wat betekent dat je naast de back-end ook meehelpt bij andere onderdelen van de code. Als softwarebedrijf bevindt KUBUS zich in een unieke positie. We bouwen aan onze eigen producten die wereldwijd door tienduizenden gebruikers worden gebruikt. Ons bedrijf heeft precies de juiste grootte: groot genoeg om echt impact te maken in de markt, maar klein

Bekijk vacature »

Fullstack developer

Functieomschrijving Heb jij kort geleden jouw HBO ICT diploma in ontvangst mogen nemen? Of ben je toe aan een andere uitdaging? Voor een erkende werkgever in de omgeving van Breda zijn wij op zoek naar een Fullstack developer. Kennis of ervaring met C# & SQL is een must! Je houdt je bezig met het ontwikkelen van nieuwe functionaliteiten; Je bent verantwoordelijk voor de beheer en ontwikkeling van de software; Je draagt bij aan de implementatie van aanpassingen, verbeteringen en aanvullingen in de C# based applicaties; Je test de software en ontwikkelt deze door; Je brengt de aanpassingssuggesties van klanten in

Bekijk vacature »

C# .NET Developer

Functie omschrijving Wij zijn op zoek naar een C# .NET Developer voor een bedrijf in de omgeving van Utrecht! Wil jij werken voor een internationaal bedrijf waar je legio mogelijkheden krijgt als Software Ontwikkelaar? Grijp nu je kans! Je kunt een uitdagende rol gaan vervullen als C#.NET Developer binnen een internationaal bedrijf dat gevestigd is in omgeving van Utrecht. Je zult gaan samenwerken met collega's die over de hele wereld verspreid zitten. Dit bedrijf is zeer vooruitstrevend en werkt met de nieuwste technieken. Als C#.NET Developer ga jij je bezig houden met het volgende: Je blijft op de hoogte van

Bekijk vacature »

Software Developer PHP

Functie omschrijving We are looking for a dutch native speaker Voor een opdrachtgever in de regio van Geldrop ben ik op zoek naar een Software Developer PHP. Jij krijgt een rol met veel verantwoordelijkheid in een groeiende organisatie. In deze functie werkt je voornamelijk remote en op een vast moment kom je met het team samen, om samen te werken en nieuwe doelen te bepalen. Wat ga je doen? Je wordt verantwoordelijk voor de interne applicatie; Je zorgt voor de doorontwikkeling van de applicatie: zowel back-end, front-end; De basis van het werk betreft front-end technieken; Periodiek bepaal je samen met

Bekijk vacature »

Medior/Senior Python developer

Functie Jij als Senior Python developer hebt al ruime ervaring opgedaan. Bedrijven komen bij de organisatie om technische vraagstukken op te lossen. Jij als specialist bent dus de representatie van deze kwaliteit. Je zult de keuze krijgen tussen lange of korte projecten waarin je komt te werken in multidisciplinaire teams. Projecten die je gaat uitvoeren zijn zeer uitlopend. Zodoende kun je aan de ene kant kiezen voor een greenfield project en stroom je bij een ander project midden in een migratietraject in. Voor de ene klant ontwikkel je ene nieuwe portal en voor het andere project duik je veel meer

Bekijk vacature »

Back-end Programmeur

Functieomschrijving Heb jij kort geleden je HBO ICT in ontvangst mogen nemen? Of ben je toe aan een nieuwe uitdaging? Voor een ambitieuze werkgever in de regio van Breda zijn wij op zoek naar een Back-end programmeur met affiniteit met C#.NET, SQL en MS Access. Samen met team bestaand uit ware ICT professionals ben je verantwoordelijk voor het bouwen van maatwerk software voor hun klanten. Belangrijk is dat je kennis of ervaring hebt van C#.NET en SQL. Je toont een flexibele en sociale houding naar klanten toe. Je denkt in nieuwe mogelijkheden & gaat graag de uitdaging aan. Bedrijfsprofiel De

Bekijk vacature »

Software Ontwikkelaar .NET te Zaandam

Bedrijfsomschrijving Je komt hier terecht bij een door-en-door softwarebedrijf, waarbinnen meerdere SaaS pakketten worden ontwikkelt voor diverse sectoren. Hierbij kun je denken aan bijvoorbeeld de logistieke en medische branche. Deze organisatie kenmerkt zich door de hoge mate van complexiteit in de applicaties, wat betekent dat jij je hier niet zal gaan vervelen. Integendeel: Jij gaat hier elke dag ontzettend veel leren en je in razend tempo ontwikkelen als C# .Net Developer met focus op back-end. Het team bestaat uit ongeveer 20 personen personen, waarvan het grootste deel zich richt op software development. De sfeer is informeel en professioneel. De producten

Bekijk vacature »

Back end developer PHP

Functie Met een complex en uitgebreid e-commerce platform, een eigen PIM-systeem en eigen scan applicatie – krijg jij dagelijks te zien hoe jouw werk gebruikt wordt door miljoenen gebruikers. En we staan qua development pas in de startblokken, aangezien er nog meerdere projecten op de plank liggen te wachten! Ons huidige development team bestaat uit 8 programmeurs. Er wordt dagelijks gereflecteerd op geschreven code, Scrum taken en kennisdelen onderling is een must. Onze voertaal binnen ons team is Engels, dit omdat wij twee internationale collega’s hebben. Ons huidige “IT Landschap” bestaat voornamelijk uit allerlei losse onderdelen die individueel, maar ook

Bekijk vacature »

Senior pega developer

You work on software that makes colleagues and customers happy! Thanks to your IT skills, De Mandemakers Groep really makes a difference for its customers. Do coding, testing and deployments make your heart beat faster? Then apply today as Senior Pega Developer at De Mandemakers Groep! Wat ga je doen? The job title gives it away: You will be developing Pega software. This ranges from technical design, coding and testing to test automation, deployments and bug fixing. Your goal is to continuously improve our systems so that colleagues can work efficiently and customers receive optimal service. You don't have to

Bekijk vacature »

Lead Java Developer

Dit ga je doen Je taken bestaan onder andere uit: Het aansturen van een development team bestaande uit 8 collega's op technisch maar ook HR gebied; Het maken van strategische keuzes omtrent de (nieuw)bouw van deze applicatie; Het maken van technische ontwerpen; Hands-on mee ontwikkelen met het team (met o.a. Java, Spring, Angular, REST); Reviewen van code en feedback geven op collega developers. Hier ga je werken Als Lead Software Developer ben je verantwoordelijk voor één van de vier Agile Java ontwikkelteams die bouwen aan technologie die duizenden instanties wereldwijd verbindt. Dit Agile team, data Jira en Confluence gebruikt en

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

29/03/2024 11:34:33
 
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.