[PHP] Vragen mbt inlog form

[Beatboxx]

Ik ben bezig met het maken van een echt degelijk login script in PHP, en nu wil ik voorkomen dat de hashes al te makkelijk gevonden kunnen worden m.b.v. een rainbow table. MD5 valt dus direct af. Ik ben in ieder geval van plan om unique salts te gaan gebruiken, maar ik wil zelfs dan dat een normaal letter+cijfer wachtwoord van 6 tekens niet makkelijk te kraken is met iemand die voor een paar tientjes wat Amazon instances huurt.

Ik heb een aantal varianten bekeken, en eentje die er in positieve zin gigantisch uitspringt is BCrypt. Voordeel is dat je het aantal "rekeying rounds" kan instellen, dus je kan zelf bepalen hoe zwaar of hoe moeilijk je het maakt om een rainbow table op te stellen.

Verder zijn er ook scripts als SHA512, maar volgens mij is het veel makkelijker om daar een rainbow table van te maken. Welk algoritme zouden jullie mij aanraden?

Verder vroeg ik me af of het verstandig was om e-mail adressen plain-text op te slaan in de database. Stel dat je database op een of andere manier (En dan doel ik niet meteen op een fout in de code zelf, maar misschien is er wel een bug in php of MySQL?) gehackt wordt? Dan wil je niet dat alle e-mail adressen op straat liggen. Hoe zouden jullie dat aanpakken?

[RobIII]

BCrypt, PBKDF2, scrypt en zo zijn er vast nog wel een paar, doen niet veel meer dan de benodigde CPU power (drastisch) verhogen om een hash te brute-forcen (key derivation). Dat zou je, in theorie, ook met een MD5 kunnen doen. Het probleem met hashes als MD5, SHA-1/2 e.d. is dat ze juist gemaakt zijn om snel te zijn en dat wil jij nou juist net niet. Deze algoritmes lossen dat op door gewoon een hele zooi "rondes" op zo'n hash los te laten (en daar tussentijds opnieuw in te salten om te voorkomen dat je keyspace steeds kleiner wordt). Idealiter zorgt 't algoritme er ook voor dat 't slecht of niet te parallelliseren is (denk aan GPU's die hier heel sterk in zijn) en dat andere manieren die 't proces versnellen (zoals caches e.d.) optimaal 'dwarsgezeten' worden in hun werk.

Beatboxx schreef op zondag 11 november 2012 @ 18:45:
Verder vroeg ik me af of het verstandig was om e-mail adressen plain-text op te slaan in de database. Stel dat je database op een of andere manier (En dan doel ik niet meteen op een fout in de code zelf, maar misschien is er wel een bug in php of MySQL?) gehackt wordt? Dan wil je niet dat alle e-mail adressen op straat liggen. Hoe zouden jullie dat aanpakken?

Je hebt 't nu over e-mail adressen, maar wat dacht je van complete NAW (als je die opslaat), of privé berichten en who-knows-what je site nog meer allemaal opslaat. Zoals altijd is 't een trade-off: hoe belangrijk zijn de gegevens en hoeveel loont 't zich om dat allemaal te encrypten? En: wil je gegevens bijv. nog doorzoekbaar hebben? Want in dat geval is 't weer een ander liedje. Er is geen "one solution fits all" antwoord hierop.

[ Voor 52% gewijzigd door RobIII op 11-11-2012 19:28 ]

[Cartman!]

Qua gemak zou ik gaan voor Bcrypt omdat deze vrij straighforward is, wil je voor de beste veiligheid gaan dan kun je gaan voor scrypt maar daarvoor zou je in PHP wel een externe module moeten installeren (een simpele hoster gaat die niet hebben en waarschijnlijk niet voor je installeren). Wil je er tussenin zitten dan kun je gaan voor PBKDF2, hier kun je nog meer dan bij Bcrypt instellen (algoritme, aantal rounds en de key lengte). Keuze genoeg dus

Qua opslag van NAW kun je wellicht gebruik maken van AES-encryptie. Wil je alleen kunnen zoeken op een exacte match dan kun je daar evt. weer een hash voor gebruiken en die los opslaan.

[Pyr0wl]

Je kan misschien eens kijken naar phpass en deze uitleg?

Ik denk toch dat dit je een heel eind op weg zal helpen

[ Voor 15% gewijzigd door Pyr0wl op 13-11-2012 11:29 ]