[PHP] Langere code

Rik schreef:

Eerdere citaten tonen

Aarclay schreef:

Nog mooier is dat je dan een salt maakt van een ander statisch gegeven van een user (registratie-ip/reg. mail ofzo)

Jep.

In mijn systemen gebruik ik sinds een tijdje dit:

Salt in de PHP zelf.
Salt per user: md5 op de userid / username / microtime o.i.d.

En dan salt1 . wachtwoord . salt2

Dan moeten ze én bij je PHP kunnen én bij je database én moeten ze ook nog eens bruteforcen. Dus tja, dan ben je ook al een tijdje bezig.

Microtime, slim gezien jahh
Gdwoon bij registratie random salt in DB zettu.

Antonn schreef:

Microtime, slim gezien jahh

Gdwoon bij registratie random salt in DB zettu.

ABN?
En als je een random salt doet? Hoe wil je bij het inloggen gaan controleren of de ingevoerde gegevens juist zijn?
Kies daarom iets *statisch*

Aarclay schreef:

Eerdere citaten tonen

Antonn schreef:

Microtime, slim gezien jahh

Gdwoon bij registratie random salt in DB zettu.

ABN?
En als je een random salt doet? Hoe wil je bij het inloggen gaan controleren of de ingevoerde gegevens juist zijn?
Kies daarom iets *statisch*

hij bedoel dat je een random code maakt bij registeren en dat dat in de data base word opgeslagen en bij de check deze weer word opgehaald uit de database (onveranderd)

Timmie schreef:

Nou een paar GPUs met een mooie rainbow table en je hebt MD5 en SHA1 zo ge brute forced

En daarom ook bcrypt (= sloooooooom = goed) + salt die per user anders is

Dylanh schreef:

Eerdere citaten tonen

Aarclay schreef:

Eerdere citaten tonen

Antonn schreef:

Microtime, slim gezien jahh

Gdwoon bij registratie random salt in DB zettu.

ABN?
En als je een random salt doet? Hoe wil je bij het inloggen gaan controleren of de ingevoerde gegevens juist zijn?
Kies daarom iets *statisch*

hij bedoel dat je een random code maakt bij registeren en dat dat in de data base word opgeslagen en bij de check deze weer word opgehaald uit de database (onveranderd)

Juist.

En dat wat lennard zegt is opzich ook wel een goede manier. Hoe slomer je encryptie, hoe slomer de decryptie voor de hackers. Maar het moet natuurlijk ook weer niet té zwaar en té sloom.

Lennard schreef:

Eerdere citaten tonen

Timmie schreef:

Nou een paar GPUs met een mooie rainbow table en je hebt MD5 en SHA1 zo ge brute forced

En daarom ook bcrypt (= sloooooooom = goed) + salt die per user anders is

Ik vermeed bcrypt altijd omdat ik het te traag vond maar ik host sinds kort op een nginx sever en wauw gewoon wauw wat draait dat lekker zeg de laad tijd is nog sneller als apache met md5.

Random code in DB zetten slaat nergens op, het hashen van wachtwoorden en andere data gebruik je juist om te voorkomen dat iemand die al IN je db zit, de wachtwoorden te weten komt.

Als je in diezelfde db al de salt hebt staan hoeven ze daar al niet meer naar te raden...

Serieus, als je met rainbow tables gaat beginnen ben je wel heel paranoide, gebruik gewoon een statische salt en je beveiliging is goed

Timmie schreef:

Eerdere citaten tonen

Lennard schreef:

Eerdere citaten tonen

Timmie schreef:

Nou een paar GPUs met een mooie rainbow table en je hebt MD5 en SHA1 zo ge brute forced

En daarom ook bcrypt (= sloooooooom = goed) + salt die per user anders is

Ik vermeed bcrypt altijd omdat ik het te traag vond maar ik host sinds kort op een nginx sever en wauw gewoon wauw wat draait dat lekker zeg de laad tijd is nog sneller als apache met md5.

Traagheid is JUIST goed en dat maakt bcrypt ook zo sterk.
Er zijn maar 2 plekken waar je bcrypt gebruikt: bij het inloggen en bij het aanmelden. Op beide paginas is het niet erg als het laden een halve seconde langer duurt, daar merk je als bezoeker niks van, en het zorgt er wel voor dat bruteforcen ook een halve seconde per wachtwoord duurt.
Dus als je een wachtwoord van 6 tekens hebt die alleen uit a-z bestaat, dan ben je al VIJF JAAR bezig om al die mogelijkheden te proberen.
Bij md5 ben je in een mum van tijd klaar. En dat is juist de kracht van bcrypt: het duurt lang en daarom is het praktisch onmogelijk dat iemand de wachtwoorden bruteforcet, je doet immers JAREN over één wachtwoord.
Bij md5 is dat aanzienlijk sneller en hebben kwaadwillenden veel eerder het wachtwoord te pakken.

En het handige van bcrypt is dat je zelf kunt instellen hoe gecompliceerd hij moet hashen, dus als er snellere computers op de markt komen dan zorg je ervoor dat hij gecompliceerder gaat hashen waardoor het bij snellere computers nog steeds lang duurt voordat ze één wachtwoord klaar hebben.

md5 is leuk maar moet je gewoon niet gebruiken als je echt veiligheid nodig hebt.

Laat maar, crypt is steedst een random code.
0100c5c515f346de1135d244574ad4face9399cd

probeer maar eens te kraken. het is een simpel wachwoord

Dylanh schreef:

Laat maar, crypt is steedst een random code.
0100c5c515f346de1135d244574ad4face9399cd

probeer maar eens te kraken. het is een simpel wachwoord

Dan gebruik je het verkeerd, bekijk dit eens http://www.gregboggs.com/php-blowfish-random-salted-passwords/

@Lennard ik heb het ooit gebruikt op een apache server met 12 rondens en het duurde +/- 5 seconde. Dat vond ik behoorlijk lang daarom heb ik toen voor een anderen manier gekozen die ook aardig lastig was omdat er logica aan te pas kwam en logica is niet te kraken dat zit in iemands hoofd.

Maar nu ik op nginx host gebruik ik weer blowfish en er is geen merkbaar verschil met bijv md5, gebruik nu maar 8 rondens maar dat zal toch niet 5 seconde verschillen met 12.

Dan moet je minder ronden doen zodat het wel binnen een acceptabele tijd is gehasht.
Elk algoritme is gebaseerd op logica, ook bcrypt, dus dat is geen argument; als je nieuwe hashmethode alsnog 0,00001 seconde per hash doet dan duurt het alsnog een korte tijd voor een wachtwoord gekraakt kan worden.

Lennard schreef:

Dan moet je minder ronden doen zodat het wel binnen een acceptabele tijd is gehasht.
Elk algoritme is gebaseerd op logica, ook bcrypt, dus dat is geen argument; als je nieuwe hashmethode alsnog 0,00001 seconde per hash doet dan duurt het alsnog een korte tijd voor een wachtwoord gekraakt kan worden.

Maar die logica is openbaar, mijn logica zit in mijn hoofd en op papier thuis. Zonder achterliggende logica kan je niet kraken.

@lennard je post was een beetje tldr, maar volgens mij klopt er het een en ander niet aan. Een goede bruteforcer wacht namelijk niet op een respons voordat hij de volgende waarde weer verzendt, maar stuurt er duizenden (?) in een seconde. Dan maakt het niet uit hoe lang je encryptie duurt. Volgens mij zijn dit de twee beste beveiligingsmethoden voor je encryptie:

1. Lange salt
2. Maximaal x keer per minuut/kwartier/whatever per IP.

Want bruteforcen wordt vergemakkelijkt door

1. Een korte string
2. Oneindig veel requests sturen

Omdat vaak ook één username wordt gebruteforced met meerdere ips kun je ervoor kiezen om x keer per IP aan te vullen met x keer per username.

Dat ligt aan je processor heb je 4 cores kan je er 4 te gelijk doen heb je er 6 dan 6. Dat hij er duizend in een seconde haalt ja dat kan zo snel is de processor dan, maar hij moet afwachten op het resultaat. Dat is ook het nut van cores anders had elke processor wel 1 core als hij toch 1000 dingen tegelijk kon doen.

Een hash kan je niet afstellen op x per minuut of ip omdat het enkel een string is geen programma o.i.d.

Bruteforcen en ip zie ik geen link tussen hoor, als je bedoelt dat je rechtstreeks met een mysql server verbind. Dan kost een request je al een eeuwigheid en haal je de 100 per seconde niet eens. En je zult een MySQL wachtwoord moeten hebben en root acces tot de server om je eigen host naam toe te voegen zodat de verbinding uberhaupt geaccepteerd wordt.

Als hackers een database in handen krijgen is dat meestal omdat er ergens een backup rond slingert of door een injectie.