wachtwoord controle

[xaltar]

Dag jongens

Op de pagina waar gebruikers hun wachtwoord kunnen wijzigen zou ik nu iets willen voorzien van een wachtwoordcontrole. Zo wil ik dat hun nieuwe wachtwoord minstens 8 tekens lang is, 1 hoofdletter en 1 cijfer bevat.
Maar ik heb geen idee hoe ik zoiets eenvoudig kan laten checken. Weten jullie raad?
Mijn form werkt, en ik ben alvast gestart met de eerste regels PHP code, maar die werken niet

<form id="wijzigWachtwoord" method="post" action="<?php echo $_SERVER['PHP_SELF'];?>">
				  <table width="279" border="0" align="center">
					<tr>
					  
					  <td align="right">Gebruikersnaam:</td>
					  <td align="right"><input type="text" id="gGebruikersnaam" name="gGebruikersnaam" value="<?php echo $_SESSION['SESS_LOGIN'];?>"/></td>
					</tr>
					<tr>
					  <td align="right">Huidig wachtwoord:</td>
					  <td align="right"><input type="text" name="gWachtwoord" id="gWachtwoord" required="required" autofocus="autofocus"/></td>
					</tr>
					<tr>
					  <td align="right">Nieuw wachtwoord:</td>
					  <td align="right"><input type="password" name="newgWachtwoord" id="newgWachtwoord" onkeyup="passwordStrength(this.value)+ match(this.value,confirmnewgWachtwoord.value)" required="required"/></td>
					</tr>
					<tr>
					  <td align="right">Bevestig nieuw wachtwoord:</td>
					  <td align="right"><input type="password" name="confirmnewgWachtwoord" id="confirmnewgWachtwoord" onkeyup="match(this.value,newgWachtwoord.value)" required="required"/></td>
					</tr>

					<tr>
					  <td>&nbsp;</td>
					  <td align="center"><input type ="submit" id="submit" name="submit" value="Wijzig wachtwoord" required="required"/></td>
					</tr>
				  </table>
				</form>

$gGebruikersnaam = $_POST['gGebruikersnaam']; 
$gWachtwoord = $_POST['gWachtwoord']; 
$newgWachtwoord = $_POST['newgWachtwoord']; 
$confirmnewgWachtwoord = $_POST['confirmnewgWachtwoord']; 

//check of pw minstens 8 tekens bevat
if($newgWachtwoord!= rand(0, 7))  
{  
print('<p class="error">Je nieuwe wachtwoord is te kort!</p>');
}
else
{
print('lang genoeg!');
}

...

Thnx voor jullie hulp!!

 

[Supersnail]

De lengte kan je controleren met de functie strlen. Voor het controleren op een hoofdletter en een cijfer kan je waarschijnlijk het beste gebruik maken van preg_match met de patterns "[A-Z]" en "[0-9]".

 

[xaltar]

De lengte kan je controleren met de functie strlen. Voor het controleren op een hoofdletter en een cijfer kan je waarschijnlijk het beste gebruik maken van preg_match met de patterns "[A-Z]" en "[0-9]".

Thnx!
En hoe ziet dat eruit in code?

 

[lord4163]

<?php

$password = "1234567";

if(strlen($password) < 8) {
	echo "You password is too short";
}

?>

 

[csshunter]

Ik denk dat er nog meer php-beveiliging bij moet komen.

• Anders kan je bv. deze krijgen: spatie-password.php
• Zie bv. ook: SQL-injectie

 

[Naarling]

Ik denk dat er nog meer php-beveiliging bij moet komen.

En niet te vergeten hashing, wachtwoorden als gewone tekst opslaan kan enorme problemen opleveren als de database onverhoopt uitlekt

• Anders kan je bv. deze krijgen: spatie-password.php

Ik zie het probleem daar niet zo. Het wachtwoord moet minstens 8 karakaters zijn, waarom zouden dat alleen letters en cijfers mogen zijn?

 

[lord4163]

Inderdaad minimaal SHA512 encryptie, MySQLI/PDO met prepared statements gebruiken en een SALT gebruiken.

http://php.net/manual/en/function.openssl-random-pseudo-bytes.php
http://php.net/manual/en/book.mysqli.php
http://www.php.net/manual/en/function.hash-hmac.php
http://crackstation.net/hashing-security.htm

@csshunter

Wat geeft dat voor veiligheidsproblemen dan? Het is alleen irritant voor de gebruiker lijkt mij, maar dat is z'n eigen schuld.

 

[PgVincent]

Even een paar hardnekkige spookbeelden wegwerken:

SHA512 is geen encryptie.

Salten is goed, maar een salt moet je opslaan in de database en als een hacker de hash van een wachtwoord uit je database kan halen dan zal de salt ook te pakken zijn. Je moet de salt dus niet gewoon voor of achter het wachtwoord plakken want dat probeert de hacker ook en dan is het hele verhaal weer triviaal.

SHA512 heeft minder collissions dan MD5, maar MD5 heeft ook geen collissions voor strings van minder dan 2Kilobyte. De enige reden waarom je een SHA512 zou nemen boven MD5 of een lagere versie van SHA is de snelheid waarmee je de hash genereert. Hoe langer dat duurt, hoe langer brute-force zal duren.

Prepared statements zijn geen magic bullet, en regelmatig zelfs zeer ongewenst omdat de database een hoop optimalisaties niet kan toepassen. Ga *niet* al je queries via prepared statements uitvoeren, maak een class die het escapen voor je doet.

PDO doet niets voor veiligheid, gewoon niets.

Wat hier niet genoemd wordt is databasetoegang. De tabellen waar de logins in staan hoeven alleen benaderd te worden door de routine die het inloggen regelt. Geef die routine een aparte user en maak de wachtwoord tabel alleen leesbaar voor die user. Dat garandeert dat geen enkele SQL-injectie of programmeerbug in de rest van je code bij die tabellen kan.

 

[Naarling]

Salten is goed, maar een salt moet je opslaan in de database en als een hacker de hash van een wachtwoord uit je database kan halen dan zal de salt ook te pakken zijn. Je moet de salt dus niet gewoon voor of achter het wachtwoord plakken want dat probeert de hacker ook en dan is het hele verhaal weer triviaal.

Niet helemaal, als je, zoals zou moeten, per gebruiker een unieke hash gebruikt moet de aanvaller elk wachtwoord opnieuw ontcijferen, het maakt dan dus niet uit of meerdere gebruikers hetzelfde wachtwoord hebben, er komt een totaal andere hash uit. Dat voorkomt uiteindelijk natuurlijk niet dat wachtwoorden ontcijferd kunnen worden maar het maakt het hele proces wel en stuk langzamer, zeker icm een langzaam hashing algoritme.

Prepared statements zijn geen magic bullet, en regelmatig zelfs zeer ongewenst omdat de database een hoop optimalisaties niet kan toepassen. Ga *niet* al je queries via prepared statements uitvoeren, maak een class die het escapen voor je doet.

PDO doet niets voor veiligheid, gewoon niets.

PDO op zichzelf doet misschien niets, maar het maakt wel het gebruik van prepared statements mogelijk, die op hun beurt weer SQL injectie voorkomen. Het is misschien niet handig om voor alle queries prepared statements te gebruiken, maar voor het inloggen lijkt het me toch wel handig. (mysqli werkt natuurlijk net zo goed). De mysql functie gebruiken is sowieso geen goed idee, die gaat immers uit PHP.

Wat hier niet genoemd wordt is databasetoegang. De tabellen waar de logins in staan hoeven alleen benaderd te worden door de routine die het inloggen regelt. Geef die routine een aparte user en maak de wachtwoord tabel alleen leesbaar voor die user. Dat garandeert dat geen enkele SQL-injectie of programmeerbug in de rest van je code bij die tabellen kan.

Goed punt.

 

[PgVincent]

Niet helemaal, als je, zoals zou moeten, per gebruiker een unieke hash gebruikt moet de aanvaller elk wachtwoord opnieuw ontcijferen

Je mist het punt denk ik; als een hacker de hash uit je database kan vissen dan is de kans zeer groot dat hij ook de salt uit de database kan vissen. Het enige wat hij dan nog niet weet is hoe je de salt toepast en als jij dus een voorspelbare manier van salten gebruikt ben je het bokkie.

Vergis je niet in hackers he, ze zijn niet te beroerd om zich b.v. aan te melden op je website om te zien of je ergens het userid gebruikt in de communicatie met de browser, zodat ze doelgericht in je database kunnen zoeken naar de hash en zo achterhalen of er wel of niet een salt is toegepast en waar die salt dan staat.

PDO op zichzelf doet misschien niets, maar het maakt wel het gebruik van prepared statements mogelijk

Dat kan ook prima met de gewone MySQL en MySQLi (ja die gaat er uit, ooit, een keer, zalnogwelevenduren.nl)

 

[lord4163]

@PgVincent

In PHP 5.5 is de mysql functie verwijderd, en dat is de nieuwe stable

 

[Tha Devil]

Meestal wordt de salt in een config bestand opgeslagen, bij een aantal frameworks welke ik ken in ieder geval.
Dan moet de hacker dus ook al toegang hebben tot je filesystem.

Als ie daar al kan komen maakt het weinig meer uit hoe je de boel beveiligd hebt.

De mysql_*-functies gaan er per PHP 5.5 uit.

 

[Naarling]

Je mist het punt denk ik; als een hacker de hash uit je database kan vissen dan is de kans zeer groot dat hij ook de salt uit de database kan vissen. Het enige wat hij dan nog niet weet is hoe je de salt toepast en als jij dus een voorspelbare manier van salten gebruikt ben je het bokkie.

Weet ik. M'n punt is dat je bij een lijst zonder uniek salt meerdere wachtwoorden in één keer kunt ontcijferen. Als je eenmaal de hash voor asdf weet, dan heb je gelijk het wachtwoord van iedereen met asdf als wachtwoord. Maar, als je per gebruiker een unieke salt gebruikt kan dat niet. Dan moet je ieder wachtwoord apart ontcijferen.

 

[PgVincent]

Maar, als je per gebruiker een unieke salt gebruikt kan dat niet. Dan moet je ieder wachtwoord apart ontcijferen.

Klopt, aparte salts maken het process moeilijker, mits zowel de salts als de saltmethode geheim blijven.

 

[xaltar]

Klopt, aparte salts maken het process moeilijker, mits zowel de salts als de saltmethode geheim blijven.

Dit zocht ik dus: http://www.the-art-of-web.com/javascript/validate-password/#.UdQmmjt7LTo ... :shocked:

 

[PgVincent]

Let wel op dat je het wachtwoord *altijd* ook aan de PHP kan moet valideren, Javsacript is alleen een indicatie naar de gebruiker toe en garandeert niets over de data die naar PHP wordt gestuurd.