[PHP] Veilige wachtwoorden

[ Voor 28% gewijzigd door dvdheiden op 11-11-2008 12:23 ]

1
2
3
4

<?php
    $salt = "hele lange en moeilijke string";
    $pass = md5("Wachtwoord".$salt);
?>

[ Voor 0% gewijzigd door DanielG op 11-11-2008 12:22 . Reden: altijd spuit 11 :p ]

marabunta2048 schreef op dinsdag 11 november 2008 @ 12:15:
dus eerst een MD5 van het wachtwoord nemen en daar vervolgens substr op uitvoeren zodat niet de gehele md5 in de database komt. Dit zorgt er ( in mijn theorie ) voor dat als de database gehackt zou worden dat de hackers niet de wachtwoorden van gebruikers in handen hebben ( er zijn genoeg sites te vinden die een database met ge-bruteforcede md5's hebben ), echter als ze niet de volledige md5 hebben maar een aantal karakters missen, dan kost het aanzienlijk veel meer moeite om 1, alle mogelijke karakters te gaan proberen, 2 alle md5's met alle karakters op mijn site te gaan proberen.

Wie kan hier iets over zeggen of dit zinnig is of niet?

marabunta2048 schreef op dinsdag 11 november 2008 @ 12:21:
Ook voor sha1 geld dat er databases (http://www.tmto.org/search/) zijn die een ongelofelijke berg wachtwoorden gewoon als sha1 en als plaintext opgeslagen hebben.. ik wil juist dat het zo veilig mogelijk is, echter misschien is een combinatie van sha1 en substr een idee?

[ Voor 13% gewijzigd door curry684 op 11-11-2008 12:46 ]

curry684 schreef op dinsdag 11 november 2008 @ 12:42:
[...]

Jij overschat lichtelijk de macht van bruteforcing. Een database met 2^128 md5 hashes of erger nog 2^160 sha1 hashes bestaat niet - daar vallen alleen mensen in met passwords als 'qwerty' en '12345'. Met een goed password is dit al per definitie geen probleem, en met salting volstrekt een non-issue.

Mocht je trouwens in de verleiding gooien om meerdere hashes over elkaar te gooien (bijv. sha1(md5($pass)) of zo) in de hoop dat dit veiliger wordt - nee daarmee verklein je ook de namespace aanzienlijk

curry684 schreef op dinsdag 11 november 2008 @ 12:42:
[...]

Jij overschat lichtelijk de macht van bruteforcing. Een database met 2^128 md5 hashes of erger nog 2^160 sha1 hashes bestaat niet - daar vallen alleen mensen in met passwords als 'qwerty' en '12345'.

writser schreef op dinsdag 11 november 2008 @ 13:14:
[...]
Maar hoeveel mensen hebben nou een goed wachtwoord?

Megamind schreef op dinsdag 11 november 2008 @ 13:09:
[...]

Hoezo is dit onveiliger?

Als je puur uitgaat van bruteforcing dan is dit toch sneller te kraken:
md5("12345");
dan dit:
md5( md5("12345") . md5("mijngeheimeuniekesalt") );

[ Voor 0% gewijzigd door T-MOB op 11-11-2008 13:41 . Reden: Iets met rekenen... ]

T-MOB schreef op dinsdag 11 november 2008 @ 13:34:
Je hebt de mogelijke variatie in je hash dus gereduceerd van 2¹²⁸ naar 64^16 = 2⁹⁶.

Megamind schreef op dinsdag 11 november 2008 @ 13:09:
[...]

Hoezo is dit onveiliger?

Als je puur uitgaat van bruteforcing dan is dit toch sneller te kraken:
md5("12345");
dan dit:
md5( md5("12345") . md5("mijngeheimeuniekesalt") );

writser schreef op dinsdag 11 november 2008 @ 13:14:
[...]

Maar hoeveel mensen hebben nou een goed wachtwoord?

[ Voor 35% gewijzigd door Cartman! op 11-11-2008 14:06 ]

edit:
Wannabe-hackers, ik heb mijn wachtwoord weer teruggezet hoor

[ Voor 10% gewijzigd door writser op 11-11-2008 14:10 ]

writser schreef op dinsdag 11 november 2008 @ 14:09:
Tja, hoeveel sites doen dat nou?

[ Voor 46% gewijzigd door RobIII op 11-11-2008 14:23 ]

[ Voor 22% gewijzigd door writser op 11-11-2008 14:38 ]

curry684 schreef op dinsdag 11 november 2008 @ 13:59:
[...] of als preg_match('#[A-Za-z]+#', $pass) true is [...]

writser schreef op dinsdag 11 november 2008 @ 14:36:
Ik had het niet tegen jou, maar tegen Curry. Er zijn genoeg sites die geen eisen stellen aan een wachtwoord en gewoon een MD5-hash opslaan (of nog erger: het wachtwoord in plaintekst opslaan en in plaintekst naar je emailen). Kennelijk zitten gebruikers niet te wachten op een systeem dat jou gaat vertellen wat voor wachtwoord je moet nemen. En als je dat niet doet is een bruteforce-oplossing wel degelijk effectief om x% van de wachtwoorden te kraken. Dus adviseer ik de topicstarter: gebruik een salt.

[ Voor 67% gewijzigd door Patriot op 11-11-2008 14:57 ]

writser schreef op dinsdag 11 november 2008 @ 14:36:
Ik had het niet tegen jou, maar tegen Curry. Er zijn genoeg sites die geen eisen stellen aan een wachtwoord en gewoon een MD5-hash opslaan (of nog erger: het wachtwoord in plaintekst opslaan en in plaintekst naar je emailen). Kennelijk zitten gebruikers niet te wachten op een systeem dat jou gaat vertellen wat voor wachtwoord je moet nemen.

[ Voor 6% gewijzigd door Data-base op 11-11-2008 19:33 ]

Data-base schreef op dinsdag 11 november 2008 @ 19:32:
Ik heb t topic niet helemaal gelezen maar wat ik vaak tegenkom is dat mensen hun wachtwoorden op de meest gekke manieren (al dan niet veilige) proberen op te slaan om te voorkomen dat t wordt gebruteforced. Maar mocht iemand je database in handen krijgen hóeft ie t niet te bruteforcen aangezien hij/zij gewoon de hash zelf in zn eigen cookie kan stoppen en klaar is kees! (even onder de aanname dat je forum cookies gebruikt om gebruikers te "onthouden").

Verder zou ik me meer druk maken over xss, csrf en sql-injection (en de gevorderden onder ons kunnen t lijstje wel verder afmaken) dan om dat iemand je wachtwoorden gaan bruteforcen.

Ontopic:
Zoals gezegd is salten een goede manier om je password veilig op te slaan. Alhoewel ik er zelf niet zo fan van ben. Dan zou ik eerder een vorm van encryptie gebruiken als je echt zo bang bent om gebruteforced te worden.

Edit:
Denk er ook vooral aan dat hashing en encryptie bouwstenen zijn voor security, en niet security zelf zijn.

Data-base schreef op dinsdag 11 november 2008 @ 19:32:
(...) Verder zou ik me meer druk maken over xss,

Data-base schreef op dinsdag 11 november 2008 @ 19:32:
(...) aangezien hij/zij gewoon de hash zelf in zn eigen cookie kan stoppen en klaar is kees! (even onder de aanname dat je forum cookies gebruikt om gebruikers te "onthouden").

Verwijderd schreef op dinsdag 11 november 2008 @ 19:44:
Zeg professor, het opslaan van hashes in plaats van de échte wachtwoorden maakt een applicatie nul komma nul veiliger of onveiliger. Het gaat erom dat je als iemand toegang heeft tot de database de wachtwoorden van iedereen niet zodanig op straat liggen, omdat ze die wachtwoorden ergens anders ook weleens zouden kunnen gebruiken.
Het kost je exact een halve minuut om de regel code te schrijven die een wachtwoord controleert, dus daari heb je helemaal gelijk. Er is gewoon geen enkel geldig excuus om een wachtwoord plain-text op te slaan. Als je het goed doet, salt je met bijvoorbeeld het emailadres. Zo kun je ook onmogelijk het te makkelijk maken om gelijke wachtwoorden uit een database te filteren. Die zijn namelijk veel makkelijker te kraken omdat ze bijna gegarandeerd in een dictionary voorkomen.

Onzin. Encryptie is niet voor het opslaan van wachtwoorden. Als je het daar wel voor gebruikt, heb je gewoon niet in de gaten waarom je een hash opslaat in plaats van het echte wachtwoord. Encryptie is haast altijd te reversen als iemand eenmaal toegang heeft tot de server, en moet je nooit gebruiken als het niet van essentieel belang is dat je het "origineel" nodig hebt. Een wachtwoord kun je altijd resetten. Het origineel boeit niet.

ibmos2warp schreef op dinsdag 11 november 2008 @ 19:51:
Je gaat toch geen password (aldanniet gehashed) in een cookie zetten , dan hoef je alleen maar effe die cookie te stelen...

Data-base schreef op dinsdag 11 november 2008 @ 20:27:
[...]

Kwam ik zo arrogant over dat je me professor noemt ja? Zo bedoelde ik het in ieder geval niet!
En tuurlijk ik zeg ook absoluut niet dat je wachtwoorden plaintext op moet slaan, maar ik vind t idee van salten maar beperkt nuttig. Iemand moet wel heel erg hard willen om 1) in je database te komen en 2) eem md5 te gaan bruteforcen (of dictioary attack) en 3) gaan proberen of iemand dat ook op andere plaatsen gebruikt (wat wrs zo is:p). Tuurlijk de kans dat dat gebeurt is absoluut niet 0, maar als iemand stap 1 en stap 2 kan doen, kan die ook je saltingalgoritme achterhalen en bruteforcen met salt. (Kerckhofss principe)

Persoonlijk zou ik vooral voor een collision gaan zoeken, en de kans dat een collision optreed is zo op t eerste oog intuitief gezien niet afhankelijk van de lengte je input. (Mn intuitie kan ook gewoon ernaast zitten hoor).

[...]

True, encryptie is niet per se voor het opslaan van wachtwoorden, maar als je per se wil dat je wachtwoorden veilig zijn, dan is encryptie veiliger. Je kan creatief doen met security protocols, en dan is zoiets als RSA veel veilger dan een md5 hash, als is het alleen omdat RSA "doen" veel langzamer is dan md5.

http://www.cl.cam.ac.uk/~rja14/Papers/SE-02.pdf (interessant stukje over security protocols )


[...]


Als je zorgt dat je security op orde is, is een cookie jatten niet mogelijk. Dat was juist heel mn punt!
Heb al tijdje geen web gedaan, maar hoe zou jij anders de "onthouden" functie maken zodat ik niet bij elk bezoek in hoef te loggen? (Behalve een sessie aan een ip te koppelen)

[ Voor 1% gewijzigd door martijnve op 11-11-2008 21:53 . Reden: typos ]

curry684 schreef op dinsdag 11 november 2008 @ 12:42:
Mocht je trouwens in de verleiding gooien om meerdere hashes over elkaar te gooien (bijv. sha1(md5($pass)) of zo) in de hoop dat dit veiliger wordt - nee daarmee verklein je ook de namespace aanzienlijk

curry684 schreef op dinsdag 11 november 2008 @ 12:42:
[...]
Mocht je trouwens in de verleiding gooien om meerdere hashes over elkaar te gooien (bijv. sha1(md5($pass)) of zo) in de hoop dat dit veiliger wordt - nee daarmee verklein je ook de namespace aanzienlijk

Confusion schreef op dinsdag 11 november 2008 @ 22:24:
[...]

Heb je daar weleens een uitleg voor gezien die voor niet-specialisten te volgen is? Googlen op die termen levert niet veel op...

   1 2 3 4 5 6 7 8 9 
a -x-------x-x-x-x-x->  A
b -/       |            
c ---x-----/            
d ---/                  
e ---------------x--->  E
f ---------\     |      
g ---------x-----/

sky- schreef op dinsdag 11 november 2008 @ 21:58:
Ik maak gebruik van een Multi-Salt systeem, gebruikers krijgen een wachtwoord toegewezen, waarna deze veranderd moet worden. Op dat moment krijgen ze een willekeurig SALT toegewezen (dit wordt bijgehouden, duh!), waardoor het al lastiger is om de salt (+ wachtwoord) te raden.

curry684 schreef op dinsdag 11 november 2008 @ 22:40:
[...]

Uhm nee je geeft ze nu 2 parallelle paden om een collision te vinden waarmee je de complexiteit aanmerkelijk verlaagt. Je hebt enkel de MTTF voor de security gereduceerd tot welk algoritme van de 2 toevallig eerder op z'n knieen gaat.

martijnve schreef op dinsdag 11 november 2008 @ 22:44:
[...]

Niet toch? want ze moetten een string vinden die op BEIDE hashes een colission geeft? kans vrijwel 0 lijkt me?

[ Voor 20% gewijzigd door curry684 op 11-11-2008 22:52 ]

Cartman! schreef op dinsdag 11 november 2008 @ 22:43:
Uh...dan kun je toch nog steeds de gebruikte salt matchen bij elke user? Ik zie het nu niet zo van dit.

martijnve schreef op dinsdag 11 november 2008 @ 22:44:
Niet toch? want ze moetten een string vinden die op BEIDE hashes een colission geeft? kans vrijwel 0 lijkt me?

curry684 schreef op dinsdag 11 november 2008 @ 22:49:
[...]

Nee omdat je ze simpel aan elkaar concat tot een string van 72 chars hoef ik maar op 1 van de 2 een collision te zoeken, tenzij ik stomtoevallig de verkeerde collision vind maar doordat je systematische beperkingen op je passwords zal hebben (te gebruiken chars en lengte) is dat aardig onwaarschijnlijk.

[ Voor 3% gewijzigd door martijnve op 11-11-2008 22:57 ]

ValHallASW schreef op dinsdag 11 november 2008 @ 22:55:
[...]

Ja, maar je moet wel voor iedere gebruiker gaan brute-forcen. Een rainbowtable maken voor één database kan nog interessant zijn, maar voor iedere gebruiker brute-forcen is bijna nooit zinvol. Daarnaast zorg je ervoor dat dezelfde wachtwoorden in de tabel niet als zodanig te herkennen zijn.

CMG schreef op woensdag 12 november 2008 @ 01:33:
Ik zou stoppen met MD5 als het op security en consequences aan komt. Maak liever gebruik van een one way hash functie (e.g.: string -> hash waarbij de hash niet terug is om te zetten in de originele string).

[ Voor 40% gewijzigd door RobIII op 12-11-2008 01:47 ]

CMG schreef op woensdag 12 november 2008 @ 01:33:
Ik zou stoppen met MD5 als het op security en consequences aan komt. Maak liever gebruik van een one way hash functie (e.g.: string -> hash waarbij de hash niet terug is om te zetten in de originele string). Zelf hoef je het wachtwoord niet te weten, je hoeft alleen maar te weten of het wachtwoord klopt, niet wat het wachtwoord is. Lees bijv. eens een artikel als http://www.cs.bham.ac.uk/...curity/lectures/hash.html

curry684 schreef op dinsdag 11 november 2008 @ 22:37:
Het is echter doordat er een vernietigende berekening wordt gedaan ondenkbaar dat de eerste 2^128 mogelijkheden zullen leiden tot 2^128 unieke hashes. Hieruit volgt dus dat de namespace kleiner wordt met iedere hash-slag omdat je de input-namespace beperkt en er dus clashes zullen gaan missen.

the expected number of N-bit hashes that can be generated before getting a collision is not 2^N, but rather only 2^(N/2)

Iow, als je stelt dat een password 8 tot 12 karakters lang moet zijn en alleen letters en cijfers mag bevatten reduceer je de input tot (62^8+62^9+62^10+62^11+62^12) mogelijkheden. Zodra je over dit password een md5 haalt heb je (62^8+62^9+62^10+62^11+62^12 minus clashes) mogelijkheden.

martijnve schreef op dinsdag 11 november 2008 @ 22:34:
[...]

Is het dan niet gewoon zo sterk als de zwakste-schakel?
Ik gebruik zelf in mn laatste project meerdere hashes paralel.
hash = md5($pass . $saltA) . sha1($pass . $saltB);
Daardoor wordt het welliswaar niet moeilijker om het wachtwoord te achterhalen, maar wel om een collission te vinden.
[...]

koffie-junk schreef op donderdag 13 november 2008 @ 08:29:
En wat als je die twee strings door elkaar gooit?

Cartman! schreef op dinsdag 11 november 2008 @ 21:50:
Als je iemand zn wachtwoord in een cookie zet is je systeem gewoon fout inderdaad. Ik kan me ook totaal niet vinden in de praat van data-base. Encryptie voor je wachtwoorden, wtf? Iemand die bij je db kan heeft 9 v'/d 10 keer ook toegang tot de rest van je code en daar staat...jawel..de key om de wachtwoorden te decrypten

Confusion schreef op woensdag 12 november 2008 @ 08:08:
Even vooraf: ik dacht altijd dat het gewoon niets hielp om sha1 en md5 gecombineerd te gebruiken, maar ik wist niet dat het geheel er zwakker van werd en ik vraag me nu af waarom dat zo is.

Data-base schreef op donderdag 13 november 2008 @ 23:23:
[...]

Ik blijf er toch bij dat encryptie gebruikt kan worden voor login systemen. Want stel je het volgende versimpelde scenario voor. Je hebt een tabel met user en daarin staat de username en de ge-encrypte username (met de wachtwoord van de gebruiker als key). Wanneer de gebruiker in wil loggen stuurt hij zijn username ge-encrypt met zijn wachtwoord als key. Als de ge-encrypte username matcht met de ge-encrypte username in de database, inloggen. Anders niet inloggen.
Als je encryptie-algoritme goed bestand is tegen een KPA, is zoiets vele malen moeilijker om te breken dan een md5hash, ook al bevat de hash een salt.

Cartman! schreef op vrijdag 14 november 2008 @ 12:20:
[...]

Dan hou je toch nog steeds als iemand toegang heeft tot je code dat ie simpelweg de wachtwoorden kan decrypten? En je hebt het enkel over md5, maar wat denk je dan van sha256 en whirlpool bijv? 256-bit hashes.

Toolskyn schreef op vrijdag 14 november 2008 @ 15:21:
[...]
Euhm nee natuurlijk niet, als je het wachtwoord dus niet opslaat, maar in plaats daarvan de username met encryptie opgeslagen, met als key je wachtwoord, dan weet je natuurlijk niet wat de key is, dus kan je als aanvaller in principe niets uithalen. De vraag is wel wat je hiermee bent opgeschoten.

RobIII schreef op vrijdag 14 november 2008 @ 15:24:
[...]

De vraag is eerder hoe diep je in de penarie zit Hoe weet je nou of een gebruikersnaam uniek is? En hoe krijg je een lijst van alle gebruikers? Om maar eens wat te noemen...

Toolskyn schreef op vrijdag 14 november 2008 @ 15:34:
[...]
Euhm je slaat natuurlijk daarnaast gewoon de plain username op, anders kun je natuurlijk nooit controleren of de decryptie is gelukt.