Wachtwoord versleutelen.

[martijn12321]

Hallo,

Ik wil wachtwoorden versleuteld gaan opslaan. Ik kwam deze tutorial tegen: https://www.youtube.com/watch?v=wIRtl8CwgIc .
Het versleutel gedeelte snap ik, maar het inlog deel en wat ik nou moet opslaan in de dtb niet.

De functie voor het versleutelen ziet er zo uit:

<?php 

function cryptPass($input, $rounds = 9){

	$salt = "";

	$saltChars = array_merge(range('A','Z'), range('a','z'), range(0,9));

	for($i = 0; $i < 22; $i++){

		$salt .= $saltChars[array_rand($saltChars)];

	}

	return crypt($input, sprintf('$2y$%02d$', $rounds) . $salt);

}

En dit is de login validatie (hij zei zelf al dat het basis was, dus nog niks met een dtb.)

$inputPass = "password";

$pass = "password";

$hashedPass = cryptPass($pass);

echo $hashedPass;

if(crypt($inputPass, $hashedPass) == $hashedPass){

	echo "<br />Password is a match = log user in";

}else{

	echo "<br />Password does not match = do not log in";

}

Kan iemand me uitleggen wat er nou in de database moet komen en hoe de validatie moet gaan?

Heel erg bedankt!!!!

(in de tutorial zitten de 2 stukken code in 1 bestand, en dan werkt het. Het probleem is dat de hash steeds anders is dus; als ik het wachtwoord ga valideren komt er een andere uit omdat de salt dan weer anders is (denk ik))

 

[ciske de rat]

hoe wil je beveiling doen wil je dat in salt hebben er zijn meerdere maniere van versleuteling

 

[PgVincent]

Als je wachtwoorden versleuteld opslaat zijn ze altijd terug te halen en omdat de sleutel zelf ook weer op de website aanwezig is moet je je afvragen waarom je de boel nog versleutelt.

Een simpele en doeltreffende manier om je wachtwoorden te beveiligen is om er een hash van te maken, met een sterke salt.
Dat maakt het onmogelijk om het wachtwoord terug te halen, maar als de eigenaar van het wachtwoord het vergeten is dan was het toch al geen best wachtwoord.

Bij het inloggen kun je het opgegeven wachtwoord simpelweg op dezelfde manier hashen en de uitkomst vergelijken met wat er in de daatabase staat.

 

[martijn12321]

@PgVincent ja, mijn code doet toch hashen met salt? Maar moet ik die salt nou in de dtb opslaan (en als dat moet, zelfde dtb als de gehashte pw's?).

@ciske de rat sorry, ik weet niet hoe het precies heet (eerste keer dat ik met versleuteling werk). In het filmpje zeggen ze: je hasht het pw met crypt() in php, het algorytme heet blowfish. Er word ook een salt gebruikt

 

[martijn12321]

@PgVincent ja, mijn code doet toch hashen met salt? Maar moet ik die salt nou in de dtb opslaan (en als dat moet, zelfde dtb als de gehashte pw's?).

@ciske de rat sorry, ik weet niet hoe het precies heet (eerste keer dat ik met versleuteling werk). In het filmpje zeggen ze: je hasht het pw met crypt() in php, het algorytme heet blowfish. Er word ook een salt gebruikt

 

[PgVincent]

Jouw script gebruikt een salt om een hash te maken en die hash is niet omkeerbaar (ik was in de war met mcrypt()) dus je hebt de salt nodig om het wachtwoord tijdens het inloggen te kunnen encoden op dezelfde manier zodat de uitkomst overeen kan komen met wat er in de database staat.

Het probleem is dat hackers aan de hash kunnen herkennen dat je crypt hebt gebruikt, en als ze de hash uit de database hebben kunnen halen dan weten ze dus ook dat de salt daar staat en wordt brute-force ineens weer mogelijk.

Goed salten verandert het wachtwoord voordat je er een hash van maakt, zodat het wachtwoord dat een hacker via brute-force zou vinden niet klopt zolang hij niet weet hoe jij de salt toepast.

 

[phobia]

Je kunt op 2 manieren gebruik maken van je salt.

1- Je maakt je een salt, $salt="DitIsMijnKorreltjeZoutVoorDeVeiligheid" en dat sla je op in een config file.
Eenmaal aan gemaakt moet je hem nooit meer veranderen omdat men dan geen toegang meer heeft tot je site.

2- Tijdens het registeren van de bezoeken maak je een salt aan om de wachtwoordhash mee te beveiligen.
Dit salt sla je samen met de wachtwoordhash op in je database.
Elke keer als de bezoeker inlogt gebruik je de salt uit de database.
Vervolgens maak je een nieuwe salt en hash je het wachtwoord met de nieuwe salt en die zet je weer in de database.
Ook maak je een login-Token hash welke je ook in de database zet en in de session bewaard.
Om nu te controleren of de gebruiken ingelogd is kijk je dan telkens of de login-Token hash in je database staat.
Staat die in de database, dan is de gebruiken al ingelogt en maak je een nieuwe login-Token hash aan welke je
weer bewaard in de database en de session. Zodat bij elke page request de gebruiken een nieuwe login-Token hash
krijgt. zijn wel minimaal 2 sql reuqests per page load, maar je wachtwoord,salt en login-Token zijn zo wel
heel dynamisch en heel lastig te breken met een brute-force of rainbow table.
Vooral als je een sha256 of sha512 gebruikt.

 

[phobia]

Je kunt op 2 manieren gebruik maken van je salt.

1- Je maakt je een salt, $salt="DitIsMijnKorreltjeZoutVoorDeVeiligheid" en dat sla je op in een config file.
Eenmaal aan gemaakt moet je hem nooit meer veranderen omdat men dan geen toegang meer heeft tot je site.

2- Tijdens het registeren van de bezoeken maak je een salt aan om de wachtwoordhash mee te beveiligen.
Dit salt sla je samen met de wachtwoordhash op in je database.
Elke keer als de bezoeker inlogt gebruik je de salt uit de database.
Vervolgens maak je een nieuwe salt en hash je het wachtwoord met de nieuwe salt en die zet je weer in de database.
Ook maak je een login-Token hash welke je ook in de database zet en in de session bewaard.
Om nu te controleren of de gebruiken ingelogd is kijk je dan telkens of de login-Token hash in je database staat.
Staat die in de database, dan is de gebruiken al ingelogt en maak je een nieuwe login-Token hash aan welke je
weer bewaard in de database en de session. Zodat bij elke page request de gebruiken een nieuwe login-Token hash
krijgt. zijn wel minimaal 2 sql reuqests per page load, maar je wachtwoord,salt en login-Token zijn zo wel
heel dynamisch en heel lastig te breken met een brute-force of rainbow table.
Vooral als je een sha256 of sha512 gebruikt.

 

[PgVincent]

1. Liever niet, want als die salt ooit wordt achterhaald zijn al je wachtwoorden tegelijk gehackt.

2. Het opnieuw hashen heeft bij elke inlog heeft geen nut. Een hacker heeft alleen die salt nodig die is gebruikt bij het maken van de hash die hij heeft. Daarmee achterhaalt hij het wachtwoord en dat de salt intussen dertien keer is veranderd maakt niet uit, jouw script is de enige die die nieuwe salt nodig heeft om de nieuwe hash te controleren tegen het oude wachtwoord.

Ook maak je een login-Token hash welke je ook in de database zet en in de session bewaard.

Niet in de session, want de session is server-side en iedereen die het id van die session heeft kan die session aanspreken, beveiligingstokens stop je in cookies, en vandaar dat je je site liefst acher SSL zet.

Zodat bij elke page request de gebruiken een nieuwe login-Token hash
krijgt.

Dat kun je doen, maar houdt er dan rekening mee dat requests wel eens fout gaan en je dus geen garantie hebt dat het token dat jij aan de bezoeker geeft ook echt door hem wordt opgepikt.
Met andere woorden; als iemand te snel op "back" klikt maak jij een nieuw token maar de bezoeker heeft die nog niet, en dan denk jij dat hij een hacker is.

 

[PgVincent]

EDIT: dubbelpost, excuus.

 

[phobia]

Laten we er wel vanuit gaan dat we niet een login maken voor een bank of super gevoelige data.
Dat is een hele andere ball game.
ja ssl veilig, maar wel beetje overkill voor een gemiddelde homemade blog/forum/site

En ja je zou nog cookies kunnen gebruiken om de browser te valideren

 

[phobia]

Laten we er wel vanuit gaan dat we niet een login maken voor een bank of super gevoelige data.
Dat is een hele andere ball game.
ja ssl veilig, maar wel beetje overkill voor een gemiddelde homemade blog/forum/site

En ja je zou nog cookies kunnen gebruiken om de browser te valideren

 

[PgVincent]

Laten we er wel vanuit gaan dat we niet een login maken voor een bank of super gevoelige data.

Nu onderschat je het probleem toch een beetje denk ik.
Het gaat er niet om of de data die jij beveiligt geveilig is, het gaat om de beveiliging van de username+wachtwoord combinatie, want *die* is gevoelig
omdat veel mensen hun gebruikersnaam en wachwood hergebruiken voor vanalles, waaronder zaken als internetbankieren, DigID etc.

Dat is dom van ze, maar het is helaas nu eenmaal zo. Je voelt je toch knap ***lig als iemand's bankrekening wordt leeggehaald omdat jij het niet nodig vond om goed na te denken over de beveiliging van jouw niet-zo-belangrijke website.

(los van dat wil je neem ik aan toch ook leren wat er wel en niet veilig is )

SSL kost niets extra en voorkomt dat je cookies worden meegelezen, waaronder dus je sessionid en je tokens.
Je cookies zelf moet je ook weer goed instellen zodat de browser ze alleen naar de originele website meestuurt.

En ja je zou nog cookies kunnen gebruiken om de browser te validere

Je *MOET* cookies gebruiken, want de session is serverside en bewijst alleen dat de browser een bepaald sessionid heeft meestuurd, dat kan ook een hacker zijn geweest die het sessionid heeft gestolen, of gegokt, of stomtoevallig nog in zijn cookies had staan. Daarom *MOET* je in de session altijd een IP controle doen.

 

[phobia]

Okey, laten we het samen eens worden.

De enige veilige computer omgeving is een standalone zonder verbinding naar buiten.
En zelfs die kan gehackt worden.

100% save is een utopie, want de mens is het grootste beveiligingslek wat er is!
ps. een ip kun je ook faken

met beveiliging moet je een afweging maken hoe gevoelig je info is die je opslaat voor de level van beveiliging die je nodig hebt.

 

[PgVincent]

met beveiliging moet je een afweging maken hoe gevoelig je info is die je opslaat voor de level van beveiliging die je nodig hebt.

Wij gaan het absoluut niet eens worden als je zulke uitspraken doet, maar verdere discussie in dit topic is niet echt op z'n plaats denk ik.

ps. een ip kun je ook faken

Het IP is nou net het enige wat je niet kunt vervalsen. Afijn, ik zou zeggen: doe je signature eer aan en google nog een beetje over beveiliging, wie weet heb ik wel een punt

 

[aaajeetee]

SSL kost niets extra

Dat is niet helemaal waar, een SSL certificaat kost wel degelijk geld. Ook is het verkeer trager dan via 'normale' http, maar met de computers van tegenwoordig merk je daar niets van.
Ik weet echter niet hoe het zit met hosting en SSL, of je webhosting-bedrijven dit aanbieden en of dit bij het pakket inzit of dat je hier extra voor moet betalen.

 

[PgVincent]

Dat is niet helemaal waar, een SSL certificaat kost wel degelijk geld.

Alleen als je een officieel geregisteerd certificaat wilt. Je kunt vaak meeliften op het certificaat van de hoster of zelf je eigen niet-geregistreerde certificaat opzetten. Het enige nadeel van een niet-geregistreerd certificaat is dat het niet erkent wordt door officiele instanties.

Ook is het verkeer trager dan via 'normale' http, maar met de computers van tegenwoordig merk je daar niets van.

Klopt, het encrypten gaat dusdanig snel dat je moet benchmarken om het te zien.

Ik weet echter niet hoe het zit met hosting en SSL, of je webhosting-bedrijven dit aanbieden en of dit bij het pakket inzit of dat je hier extra voor moet betalen.

De meeste bieden het aan en of je ervoor moet betalen hangt af van hoeveel bits encryptie je wilt etc.

 

[martijn12321]

Sow, da's veel info allemaal .
Ja, ik was zelf ook al tegen SSL aangelopen. Als je gewoon voor de link https zet geeft chrome in ieder geval al een error en ik denk dat dat toch wel wat mensen af zou schrikken. Mijn hosting heeft nergens iets staan van SSL (ik ga versio nemen, is heel goedkoop, 99% uptime garantie en zonder onzin). SSL los kopen is (goedkoopste variant, er waren 3 soorten) 10 euro per jaar. Als je meerdere jaren in 1 keer kocht krijg je korting.Binnen 10 minuten zou je certificaat klaar zijn voor gebruik. Dit was trouwens niet echt na diepe research maar gewoon een van de eerste van google, dus kan misschien goedkoper.

 

[PgVincent]

Als je gewoon voor de link https zet geeft chrome in ieder geval al een error

natuurlijk, je moet het web op je webserver aanzetten he

en ik denk dat dat toch wel wat mensen af zou schrikken.

Helemaal niemand. SSL is heel gebruikelijk tegenwoordig en het enige wat de bezoeker ervan ziet is dat er een slotje oplicht in zijn toolbar of statusbar.

Mijn hosting heeft nergens iets staan van SSL (ik ga versio nemen, is heel goedkoop, 99% uptime garantie en zonder onzin).

Zo zijn er meer hoor

SSL los kopen is (goedkoopste variant, er waren 3 soorten) 10 euro per jaar.

Dus nog geen euro in de maand, daar kun je niet meer over vallen

 

[martijn12321]

Haha, ik bedoelde met dat afschrikken: door die error.
En die error komt zolang je geen geldig SSL certificaat hebt.
En dat krijg je niet zonder te betalen. (Dit zei ik omdat iemand zei dat ssl niks extra's zou kosten)