[PHP] Langere code

Timmie schreef:

Maar die logica is openbaar, mijn logica zit in mijn hoofd en op papier thuis. Zonder achterliggende logica kan je niet kraken.
Met als verschil dat als jouw site gehackt wordt en mensen kunnen op een of andere manier bij je bestanden, dan zien ze hoe jij de boel hasht. En niet lullig bedoeld, maar ik denk niet dat je hash veiliger is dan een hash die al jarenlang gebruikt wordt en door tigduizenden developers is verbeterd en versterkt, dus dan kun je beter een openbare logica hebben die zelfs dán niet gekraakt wordt.

Fass schreef:

Een goede bruteforcer wacht namelijk niet op een respons voordat hij de volgende waarde weer verzendt, maar stuurt er duizenden (?) in een seconde.
Dat heeft geen zin. Je processor kan maximaal x berekeningen per seconde doen, en dat is je bottleneck. Ga maar eens een bestand van 100 MB zippen. Hij doet er een paar seconden over dan, maar als je er 5 tegelijk laat zippen dan duurt het al veel langer, en als je er duizenden tegelijk doet dan duurt het gewoon onwijs lang voordat het klaar is. Zelfde met hashen; dat moet gewoon allemaal berekend worden, of je er nou 1 of 3023409230 per seconde start.

Fass schreef:

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.

Volgens mij begrijpen we elkaar verkeerd. Ik doelde erop wat er kan gebeuren als iemand je gehashte wachtwoord heeft doordat bijvoorbeeld je database is gelekt. Als dat zo is dan heb jij er totaal geen controle meer over hoeveel pogingen per seconde iemand kan doen en dan is ook je salt openbaar als je code ook is gelekt, dus dan heb je aan beide maatregelen helemaal niks. En daarom hamer ik er zo op dat de hashprocedure gewoon langzaam is, want dan duurt het ALTIJD lang om achter een wachtwoord te komen; ook al heeft de aanvaller je salt, ook al heeft de aanvaller je algoritme, ook al kan hij alles in je host zien, enzovoort. Hij weet alles, maar de wachtwoorden zal hij nooit te weten komen binnen afzienbare tijd, en dat is met sha, met md5 of met een of andere selfmade hashmethode wel het geval.

Dat klopt inderdaad en de algoritmen is gebaseerd op verschillende bestaande hash functies. Zo wordt bijvoorbeeld een MD5 string door elkaar gehutseld op basis van een CRC. Niet echt een eigen hash functie maar de logica erachter wel. Deze logica kan natuurlijk zo gezien worden als er ingebroken wordt.

Kyron schreef:

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

Dubbele beveiliging. Je moet én een general salt én een user-specific salt gebruiken. De hacker moet dan voor elke gebruiker opnieuw de salt ophalen en verwerken. Terwijl je bij een general salt gewoon de string op alle wachtwoorden kan toepassen; iets wat een stuk sneller is.

Timmie schreef:

Eerdere citaten tonen

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.

Security through obscurity. Iets waar je niet op moet vertrouwen. Althans, je moet niet énkel op Security through obscurity vertrouwen. Gebruik altijd een beproefde methode.

Rik, ik doelde op het punt waar je een random code in de database stopt. Als je een gebruiker zijn email, of ip, of registratiedatum op een speciale manier gebruikt komt niemand erachter, maar als je gewoon een onderdeel "randomvoorsalt" in je database zet is het nutteloos,

user-specific info is handig maar maak er geen speciaal iets voor aan, zoals jij net ook al zei bijv dus gewoon het registratie ip of iets dergelijks.

^ Nee uiteraard. Daarom zei ik ook een md5 op de microtime + username ofzo.

Ik gebruik salt en sha1, dan hash ik ze en heb ik ook nog een beveiliging die het aantal keren inloggen per minuut limiteerd tot tien keer. Timmies manier met de split() functie lijkt me ook wel interessant.

Rik schreef:

^ Nee uiteraard. Daarom zei ik ook een md5 op de microtime + username ofzo.

Geen microtime Die verschilt steeds

Antonn schreef:

Eerdere citaten tonen

Rik schreef:

^ Nee uiteraard. Daarom zei ik ook een md5 op de microtime + username ofzo.

Geen microtime Die verschilt steeds

Kan wel, maar dan moet je gewoon de microtime van de registratiedatum pakken en die opslaan, zodat hij voor een bepaalde user steeds de zelfde microtime pakt.

Antonn schreef:

Eerdere citaten tonen

Rik schreef:

^ Nee uiteraard. Daarom zei ik ook een md5 op de microtime + username ofzo.

Geen microtime Die verschilt steeds

Dat is juist de bedoeling. Je wilt dat de userspecific salt (die je opslaat) steeds anders is voor elke gebruiker Maar het moet niet te achterhalen zijn (een md5 op de username is dus niet genoeg).

Maar je moet wel bij een login die salt beschikbaar hebben om op het wachtwoord te kunnen controleren. Dus dan zou ik altijd voor een statische salt kiezen.

microtime() is dus GEEN optie. Het verbaast me dat dat deze hele discussie gewoon vier paginas groot is, terwijl ik al de beste manier heb verteld.

Kijk mijn nieuwe mislukted oplossing:

Maak 2 databases, 1 met salts en 1 met wazchtwoorden. Geen gezeik meer van "Als ze je MD5 hebben hebben ze ook je salt"

En waarom in godesnaam twee databases?
Omdat je het idee wilt laten falen? Als ze de ene database hebben, komen ze ook bij de andere....

Echt het beste idee door mij is al geroepen, gewoon op het registratie IP of registratiemail of een combi ervan een salt genereren. Altijd statisch en hoppa.....

Aarclay schreef:

Maar je moet wel bij een login die salt beschikbaar hebben om op het wachtwoord te kunnen controleren. Dus dan zou ik altijd voor een statische salt kiezen.

microtime() is dus GEEN optie. Het verbaast me dat dat deze hele discussie gewoon vier paginas groot is, terwijl ik al de beste manier heb verteld.

SELECT pass, salt FROM users WHERE username = $_POST[username]

Tadaa, probleem opgelost. Microtime is dus WEL een optie.
Dus jouw manier is niet per defenitie de beste, dus een beetje minder arogant mag ook wel. Het is niet voor niks een forum waarop je kunt discussiëren.

Niks arrogant
En een salt in de database zetten, is hetzelfde als de sleutel naast mijn voordeur hangen als ik naar mijn werk ga.
Een grote no-go... De salt moet koste wat koste voor iedereen geheim zijn, daarom is deze altijd in de source gedefineerd. (en dan liefst buiten de webroot)

Rik schreef:

SELECT pass, salt FROM users WHERE username = $_POST[username]

Tadaa, probleem opgelost. Microtime is dus WEL een optie.
Dus jouw manier is niet per defenitie de beste, dus een beetje minder arogant mag ook wel. Het is niet voor niks een forum waarop je kunt discussiëren.

Dat is dus wat ik zeg, als je de salt gewoon in de database zet heb je er alsnog heel weinig aan.