[PHP] If doet niet wat ie moet doen

[Beatboxx]

Ik heb een extreem raar probleem met PHP. Ik ben bezig met een login script. Bij het registreren maak ik via random een salt voor die user, die ik in de MySQL table opsla. We hebben dus de tabel users met daarin id, username, password en salt.

PHP:

//Prevent injection
$_POST['password'] = stripslashes($_POST['password']);  
$info['password'] = stripslashes($info['password']);
// Set variable from database
$salt = $info['salt'];
//crypt user-input
$pass = crypt($_POST['password'], $salt);
//Output for debugging
echo $pass;
echo "</br>";
echo $info['password'];
echo "</br>";
    
}   


 //gives error if the password is wrong

    if ( $pass == $info['password'] ) {
//Just testing if it works.
    echo '2';   
    
    else  { 
//If password is wrong, close
 die('Incorrect password, please try again.');
   }

Wat er nu uitkomt is dit:

quote: output

xxxxxxxxxxxxx
xxxxxxxxxxxxx
Incorrect password, please try again.

Ik heb beide output's ff als xxxx opgeschreven. Neem van mij maar aan dat ze exact hetzelfde zijn. Toch komt er incorrect password uit, dus ze zijn volgens php niet hetzelfde. Als ik

PHP:

if ( $pass == $info['password'] ) {

verander in:

PHP:

if ( $pass != $info['password'] ) {

wordt 2 wél ge-echo't, maar dan echo't ie twee voor elke waarde, tenzij ik dit neerzet:

PHP:

if ( $pass != 'xxxxxxxxx' ) {

Dan werkt het wel.

Kortom het probleem, hij wil ze niet vergelijken. Wat doe ik fout? Het betreft een wampserver met php 5.3.8

[ Voor 0% gewijzigd door Beatboxx op 22-10-2011 15:39 . Reden: spatie+foute variable(lost probleem niet op) ]

[naam]

Je gebruikt in de if $datapassword, terwijl je $pass telkens set?

nvm.

[ Voor 10% gewijzigd door naam op 22-10-2011 15:41 ]

[Ventieldopje]

Er is niks mis met je if, ook niet met je php. Doe maar eens een strlen() op beide strings of waarschijnlijk om het op te lossen een trim()

[SvMp]

Dit soort "debugging":

code:

echo $pass;
echo "</br>";
echo $info['password']; 
echo "</br>";

zou ik doen met

code:

var_dump($pass);
var_dump($info['password']);

[HuHu]

PHP:

//Prevent injection 
$_POST['password'] = stripslashes($_POST['password']);     
$info['password'] = stripslashes($info['password']);

• Dit is geen goede manier van "prevent injection", wat je daar ook mee bedoelt. Pas nóóit (!) de $_POST direct aan.
• Waar komt $info vandaan?

Als je database-acties doet, dan doe je pas op het moment dat je de query bouwt iets als mysql_real_escape_string (als je MySQL gebruikt). Niet zomaar blind stripslashes overal overheen gooien. Dat helpt sowieso niet tegen SQL injection en waarom zou iemand geen slash in z'n wachtwoord mogen hebben?

[Ventieldopje]

Bovendien lijkt het me ook niet handig als iemand je database weet binnen te komen dat ze ook automatisch de salt bij elke gebruiker zien staan dan is het hele nut van de salt weg, dit soort dingen moet je hard coden in je applicatie in bijv. de configuratie

[SvMp]

Die stripslashes zijn volgens mij overbodig. Waarom stripslashes gebruiken op iets dat uit de database komt? De inhoud van $_POST['password'] gaat niet rechtstreeks een query in, maar wordt gecodeerd met de functie crypt.


EDIT: Ik heb het script even gecopy-paste en geprobeerd. Het werkt hier gewoon, maar er zijn wel fouten. Zo staat er een '}' verkeerd, en ontbreekt er een '}' bij de 'else' aan het eind.

Dit is een fragment uit een groter stuk code. Er lijkt wat geknipt en geplakt te zijn waardoor een mogelijk probleem hier helemaal niet zichtbaar wordt. Staat dat if-statement op dezelfde plek als je debug-echo's?

Deze test:

PHP:

$_POST['password']='test';
$info['password']='twBJx7xNo03Eo';
$info['salt']='tweakers';

//Prevent injection
$_POST['password'] = stripslashes($_POST['password']);    
$info['password'] = stripslashes($info['password']);
// Set variable from database
$salt = $info['salt'];
//crypt user-input
$pass = crypt($_POST['password'], $salt);
//Output for debugging
echo $pass;
echo "</br>";
echo $info['password'];
echo "</br>";
    
var_dump($pass);
var_dump($info['password']);


 //gives error if the password is wrong

     if ( $pass == $info['password'] ) {
//Just testing if it works.
     echo '2';    
    
  }  else  { 
//If password is wrong, close
 die('Incorrect password, please try again.');
   }

Functioneert zoals het moet.

Het kan wel compacter:

PHP:

   // Dit onderbrengen in een config-file die ergens ge-include wordt
   define('CONFIG_SALT', 'tweakers');

   // Password check
   $pass = crypt($_POST['password'], CONFIG_SALT);
   if ( $pass == $info['password'] ) {
      //Just testing if it works.
      echo '2';    
   } else {
      //If password is wrong, close
      die('Incorrect password, please try again.');
   }

[ Voor 157% gewijzigd door SvMp op 22-10-2011 16:07 ]

[NMe]

Ventieldopje schreef op zaterdag 22 oktober 2011 @ 15:46:
Bovendien lijkt het me ook niet handig als iemand je database weet binnen te komen dat ze ook automatisch de salt bij elke gebruiker zien staan dan is het hele nut van de salt weg, dit soort dingen moet je hard coden in je applicatie in bijv. de configuratie

Niet dus. Het doel van een salt per gebruiker is dat je dat niet zomaar je hele database tegen een rainbow table aan kunt leggen want je zal een rainbow table per gebruiker moeten maken. Als je één hardcoded salt hebt, heb je met één rainbow table genoeg.

Ontopic: zoals SvMp al zegt is er behoorlijk wat mis met het accoladegebruik, fix dat eerst even. Hint: netjes inspringen met tabs, want deze spaghetti is niet te lezen.

[thegve]

Een if die niet doet wat ie moet doen is over het algemeen een verschil qua variabele type, normaal gesproken gooit PHP die direct voor je om, aangezien het een weak-typed taal is.

Daarom moet je, als je dit niet wilt, en dat wil je meestal niet, === gebruiken in plaats van ==. === zorgt ervoor dat als je een string met een cijfer vergelijkt dit altijd 'false' teruggeeft.

PHP:

<?php
    $variabele_a = 'henk';
    $variabele_b = 0;

    $bool = ($variabele_a == $variabele_b);
    var_dump($bool);
    $bool = ($variabele_a === $variabele_b);
    var_dump($bool);

code:

$ php example.php 
bool(true)
bool(false)

[SvMp]

@NMe: Je hebt gelijk, mijn suggestie met die globale salt is minder goed. Volgens mij is een globale salt nog wel waardevol als de kans bestaat dat de database wordt gestolen zonder de scripts. Bijvoorbeeld als database en scripts op verschillende servers staan.

@thegve: Jouw suggestie is iets om rekening mee te houden in situaties waarbij twee variabelen ten onrechte als gelijk worden gezien. In het probleem van de topicstarter worden twee variabelen echter als ongelijk beschouwd tegen de verwachtingen in.

[ Voor 28% gewijzigd door SvMp op 22-10-2011 16:27 ]

[Beatboxx]

Die salts komen uiteindelijk ook in een andere database (Lijkt me veilig?). Info komt uit de database. Trim werkt=D Ik ga morgen wel eens rustig googlen op: How to prevent MySQL attack. Ik denk dat dat icm een goede MySQL-firewall het probleem moet oplossen=D

Maar mijn huidige oplossing, met salts in dezelfde database, is dat een goede oplossing?

[Gomez12]

SvMp schreef op zaterdag 22 oktober 2011 @ 16:23:
@NMe: Je hebt gelijk, mijn suggestie met die globale salt is minder goed. Volgens mij is een globale salt nog wel waardevol als de kans bestaat dat de database wordt gestolen zonder de scripts. Bijvoorbeeld als database en scripts op verschillende servers staan.

Dat vind ik altijd zo'n raar uitgangspunt...

Of ik ga ervanuit dat niemand binnenkomt (fat chance)
Of ik ga ervanuit dat iemand overal binnenkomt.

Zoals jij het stelt zeg je eigenlijk dat je dbase simpelweg minder beveiligd is dan je scripts... Daar moet je wmb een heel erg goede reden voor hebben anders zou ik gewoon zeggen beveilig ze allebei...

[Beatboxx]

Als we toch bezig zijn, meteen nog een vraag. Als de gebruiker is ingelogd krijgt deze een cookie mee met daarin de username en het wachtwoord (plain text). Elke pagina zoekt aan de hand van de username de bijbehorende salt op, en crypt het wachtwoord met die salt die dan wordt vergeleken met de salt die bij die username hoort in de database. Goeie methode? Afaik wel.

[Ramon]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 17:11:
Als we toch bezig zijn, meteen nog een vraag. Als de gebruiker is ingelogd krijgt deze een cookie mee met daarin de username en het wachtwoord (plain text). Elke pagina zoekt aan de hand van de username de bijbehorende salt op, en crypt het wachtwoord met die salt die dan wordt vergeleken met de salt die bij die username hoort in de database. Goeie methode? Afaik wel.

Nee natuurlijk niet. In je cookie zet je sessie informatie die de sessie identificeerd die je in je db hebt opgeslagen. Géén plain text passwords

[Beatboxx]

Maar diegene die het cookie kan opvragen is ook degene die 'm heeft getypt toch? Die weet 'm dus sowieso al:S

[SvMp]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 17:24:
Maar diegene die het cookie kan opvragen is ook degene die 'm heeft getypt toch? Die weet 'm dus sowieso al:S

Een gevaarlijk misverstand waarbij je er van uit gaat dat er nooit iemand anders achter die computer zit.

Gebruikersnaam en wachtwoord stop je in een sessie. In het cookie komt alleen het sessie-ID. Vervolgens beveilig je de sessie tegen hijacking.

[ Voor 18% gewijzigd door SvMp op 22-10-2011 17:39 ]

[HuHu]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 17:24:
Maar diegene die het cookie kan opvragen is ook degene die 'm heeft getypt toch? Die weet 'm dus sowieso al:S

Tip: ga je veel beter verdiepen in dit onderwerp, want het blijkt niet dat je er iets van snapt.

Als ik nu achter iemand z'n computer ga zitten, dan kan ik zo het cookie met het wachtwoord opzoeken. Als ik met XSS je site overneem, dan heb ik ook iemand z'n cookie. Enz...

Er is absoluut geen reden dat iemand z'n wachtwoord in een cookie staat, dus doe het niet.

[Beatboxx]

Ok:) Ik weet dat ik veel moet leren;). Ik post zo wel wat ik nu heb veranderd.

[Verwijderd]

crypt() zet standaard de salt in het resultaat (random by default):

PHP:

$password = "test";
$hash = crypt($password); //string(34) "$1$SWaZAkEm$QjboBqwGQ.YPXSR3xFP.2."
var_dump(crypt($password, $hash) == $hash); //bool(true)

Zie http://php.net/crypt

[Bv202]

Volgens mij is een globale salt nog wel waardevol als de kans bestaat dat de database wordt gestolen zonder de scripts.

Als de kans bestaat dat je database "gestolen" wordt, moet je eens dringend gaan kijken naar de veiligheid van je database, want op die manier gaan redeneren is echt foutief.

[SvMp]

Bv202 schreef op zaterdag 22 oktober 2011 @ 20:06:
[...]

Als de kans bestaat dat je database "gestolen" wordt, moet je eens dringend gaan kijken naar de veiligheid van je database, want op die manier gaan redeneren is echt foutief.

Je mag die kans nooit uitsluiten. Velen die ooit beweerden dat hun server onkraakbaar is, zijn onderuit gegaan. Kijken naar de veiligheid van database en server is wat mij betreft vanzelfsprekend.

[ Voor 9% gewijzigd door SvMp op 22-10-2011 20:23 ]

[Beatboxx]

Als ik aan dingen zoals salten e.d. werk, ga ik er vanuit dat die redelijk makkelijk te bereiken zijn, en dat iemand daar dan nog niks mee moet kunnen. Als ik injection's probeer te voorkomen, houd ik in mijn achterhoofd dat als ze de database te pakken krijgen ik de lul ben. In het echt is het een middenweg, het is nooit onmogelijk om de database te pakken te krijgen, maar het is ook nooit onmogelijk om salt's 100% veilig te maken!!

[Ventieldopje]

Bv202 schreef op zaterdag 22 oktober 2011 @ 20:06:
[...]

Als de kans bestaat dat je database "gestolen" wordt, moet je eens dringend gaan kijken naar de veiligheid van je database, want op die manier gaan redeneren is echt foutief.

Ik denk dat de kans groter is dat ze een SQL dump kunnen doen - en dan een salt in de db dus geen enkel nut heeft - dan inbreken op je website (zowel db als bestanden). Hackers zijn immers uit op je data en niet op je site zelf.

Als hackers een SQL dump maken dmv. SQL injection oid. en je wachtwoorden zien en niet het salt weten zijn ze een stuk langer bezig

[Verwijderd]

Ventieldopje schreef op zaterdag 22 oktober 2011 @ 20:35:

Als hackers een SQL dump maken dmv. SQL injection oid. en je wachtwoorden zien en niet het salt weten zijn ze een stuk langer bezig

Ja, maar zover hoeft je beveiliging niet te gaan. Je kunt de salt gewoon bij de gebruiker opslaan. Dat doet bijvoorbeeld het crypt algoritme ook. En bijvoorbeeld Linux in /etc/shadow ook. Een wachtwoord is niet ineens onveilig als de salt bekend is. Die salt is niet eens zo belangrijk, als hij maar random en uniek is.

Laat het beveiligen van webapplicaties lekker over aan mensen die er verstand van hebben, in plaats van met je wel goed bedoelde maar niet correcte tips te komen.

[Beatboxx]

@Cheatah hoe wil je dan inloggen als de gebruiker wat files verwijderd/op een andere pc zit?

[cariolive23]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 17:07:
Ik ga morgen wel eens rustig googlen op: How to prevent MySQL attack. Ik denk dat dat icm een goede MySQL-firewall het probleem moet oplossen=D

Dus eerst een lek systeem maken en dan de boel proberen af te schermen met een firewall? Dat is het bekende paard achter de wagen spannen...

Zorg gewoon voor een veilig systeem, dan is de basis tenminste goed. Prepared statements doen al jaren wonderen, daar valt namelijk niks meer in te injecteren wat kan worden uitgevoerd: Het queryplan is al opgesteld. Bewezen techniek en kinderlijk eenvoudig.

[Beatboxx]

Daarmee bedoel je dat er geen variabelen inzitten?

[SvMp]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 21:07:
Daarmee bedoel je dat er geen variabelen inzitten?

Die vraag kun je voor jezelf beantwoorden door mijn eerder in dit topic gegeven advies te volgen: Je verdiepen in MySQLi. En die oude MySQL-extension er uit gooien, tenzij je echt geen andere keuze hebt.

[Gomez12]

Ventieldopje schreef op zaterdag 22 oktober 2011 @ 20:35:
[...]
Als hackers een SQL dump maken dmv. SQL injection oid. en je wachtwoorden zien en niet het salt weten zijn ze een stuk langer bezig

Waarmee zijn ze dan langer bezig?

Ze zijn enkel langer bezig in het theoretische geval dat ze van 1 user het pw willen hebben.

10.000 salts voor 10.000 pw'en zijn iets sterker dan 1 salt voor 10.000 pw'en

[Beatboxx]

En voor al die salts bestaan vast geen rainbow table:S Maar dan is het nog veiliger om nog een andere database te maken voor puur de salts? Dan moet ie nog die database te pakken zien te krijgen?

Ik ga me morgen in MySQLi. Wat ik nu heb gedaan, elke waarde haal ik voordat die in een mysql_query gaat met mysql_real_escape_string() behandelen. Dan ben ik iig verder dan de Nederlandse overheid Maar hoe veilig is dit?

EDIT:

Het cookie bestaat nu uit de username in plain-text, en een sessionid. Daarop ben ik gekomen door een random value, samen met een combi van username+password en wat hashes . Het lijkt me dat sessionid niet elke keer hetzelfde hoeft te zijn?

[ Voor 23% gewijzigd door Beatboxx op 22-10-2011 21:30 ]

[YopY]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 21:28:
En voor al die salts bestaan vast geen rainbow table:S Maar dan is het nog veiliger om nog een andere database te maken voor puur de salts? Dan moet ie nog die database te pakken zien te krijgen?

'Security through complexity'? (ik bedenk die term spontaan - een loginsysteem wordt niet noodzakelijk veiliger als je het complexer maakt door bijv. die data in een andere database op te slaan. Als je server gecompromitteerd wordt en - bijv - de PHP code met daarin de databasegegevens achterhaald wordt ben je nog even hard de sjaak.)

Gewoon pw + salt doen, waar je ze opslaat maakt volgens mij niet zo heel veel uit, en als je DB gejat wordt gewoon een algehele password reset doorvoeren oid - het zal in de praktijk niet zo heel vaak voorkomen, en dan nog moet je je afvragen hoe erg het is en/of hoe veel (tijd / geld) je ervoor over hebt om het te voorkomen.

Beatboxx schreef op zaterdag 22 oktober 2011 @ 20:53:
@Cheatah hoe wil je dan inloggen als de gebruiker wat files verwijderd/op een andere pc zit?

Een salt voor één specifieke login misschien? Maar da's effectief hetzelfde als een session-id.

[Voutloos]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 21:28:
Het lijkt me dat sessionid niet elke keer hetzelfde hoeft te zijn?

Sterker nog, session ids herbruiken/constant houden zou een grove fout zijn. KISS, gewoon random met voldoende mogelijke waardes en klaar.

YopY schreef op zaterdag 22 oktober 2011 @ 21:33:
Een salt voor één specifieke login misschien? Maar da's effectief hetzelfde als een session-id.

Stop, spraakverwarring. Cheatah bedoelde enkel dat je de salt op dezelfde plek als de rest van je user data op kan slaan.

Alle data blijft dus serverside, het enige dat client hoeft te onthouden is een random sessie id.

[ Voor 43% gewijzigd door Voutloos op 22-10-2011 21:51 ]

[Beatboxx]

Ik schets ff wat ik nu heb:

Gebruiker registreert. Via dit script wordt een salt gemaakt:

PHP:

function Random($length=128){  
    $key = '';  
    $pattern = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*";  
    for($i=0;$i<$length;$i++){  
        $key .= $pattern{rand(0,69)};  
        }  
    return $key;  
}

Via deze salt wordt het password gecrypt, en in de database gezet op een rij met username, password, salt en een lege kolom voor sessionid.

Als een gebruiker in wilt loggen zoekt ie in de database de bijbehorende salt voor de ingegeven username op. mysql_num_rows == 0? Username bestaat niet, sleep, register form. Het ingegeven wachtwoord wordt met de gevonden salt encrypted, en de beide paswordhashes (De net gegenereerde en die uit de database) worden vergeleken. Zijn ze hetzelfde? (===), dan wordt er een cookie aangemaakt. Een cookie met sessionid (Die gewoon met random wordt gemaakt), en dat sessionid wordt ook in de database in de kolom sessionid opgeslagen.

Wil een gebruiker login-content bekijken? Dan SELECT ik WHERE sessionid = $id_van_cookie. mysql_num_rows == 1? admin content. Else? header(login.php)

Is dat een beetje in orde?

[Ramon]

Beatboxx schreef op zaterdag 22 oktober 2011 @ 22:40:
Ik schets ff wat ik nu heb:

....

Is dat een beetje in orde?

Wat gebeurt er nu als ik op plek A ben ingelogd en ik log later op plek B in?

[thegve]

Als de kans bestaat dat je database "gestolen" wordt, moet je eens dringend gaan kijken naar de veiligheid van je database, want op die manier gaan redeneren is echt foutief.

De beste beveiliging is dat je meerdere lagen van beveiliging opstelt. Zo zou je best een heel veilig inlogsysteem kunnen maken, en je wachtwoorden vervolgens cleartext opslaan. Dat doe je niet, omdat er een kans is dat iemand de beveiliging kraakt.
Ga uit van de aanname dat je webserver gekraakt is en ga uit van de aanname dat je database gekraakt is, en probeer je voor beide zo goed mogelijk te beveiligen. Jouw redenatie dat het "onmogelijk" is dat jouw database gekraakt is, is echt een erg gevaarlijke aanname.

edit:
Volgens mij word er behoorlijk afgedwaald van het onderwerp verder:

@TS:
Plaats wat completere code, desnoods haal je hier wat zoek en vervang opdrachten overheen als er specifieke namen/dingen in staan, dat werkt makkelijker.
En voor testen moet je inderdaad echt gebruik maken van var_dump (of iets als zend server debugging, maar houd het voorlopig maar op var_dump).

[ Voor 21% gewijzigd door thegve op 23-10-2011 00:16 ]

[Beatboxx]

We hebben register.php:

PHP:

$username = mysql_real_escape_string($_POST['username']);
$pass = mysql_real_escape_string($_POST['pass1']);
$salt = $random();

$passwordhash = crypt($pass, $salt);

mysql_query("INSERT INTO
users
(username, password, salt)
VALUES
('".$username."', '".$passwordhash."', '".$salt."')");

login.php:

PHP:

username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']);
$check = mysql_query("SELECT * 
                    FROM users 
                    WHERE username = '".$username."'")or die(mysql_error());
if(mysql_num_rows($check) == 0)
    { echo 'De opgegeven gebruikersnaam is niet gevonden'; }
    
    
while($info = mysql_fetch_array( $check ))  

 {

 $password = $_POST['password'];
    
    $info['password'] = $info['password'];

    $salt = $info['salt'];
    $pass = crypt($password, $salt);
    $datapass = $info['password'];
    $pass = trim($pass);
    $datapass = trim($datapass);
    
}   


 //gives error if the password is wrong

    if ( $pass === $datapass ) {

//Make sessionid
    $userpass = $_POST['username'].$_POST['password'];
    $userpass = md5($userpass);
    //Generate the random value
function Random($length=10){  
    $key = '';  
    $pattern = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*";  
    for($i=0;$i<$length;$i++){  
        $key .= $pattern{rand(0,69)};  
        }  
    return $key;  
}  
    $random = random()
    
    //Melt userpass and random value together
    $sessionid = $random.$userpass;
        mysql_query("
        UPDATE 
        users
        SET
        last_sessionid = '".$sessionid."'
        WHERE
        username= '"$username"'
");

//if login is ok then we add a cookie 

    

     $expire = time() + 1800; 

 setcookie('cookiename', $sessionid, $expire);  
    
    }
    else 
    
 { 

 die('Het wachtwoord was onjuist. Probeer opnieuw');
  

 }

Member-area.php

PHP:

if(isset($_COOKIE['cookiename'])) 

 { 
    $sessionid = mysql_real_escape_string($_COOKIE['cookiename'])   ;
    $check = mysql_query("SELECT * FROM users WHERE last_sessionid = '".$sessionid."'")or die(mysql_error()); 
    if(mysql_num_rows($check) == 1 ) {
        echo 'member content'; }
    else {
        header("location: login.php");
            }
}
else {
    header("location: login.php");
}

Dit zijn niet de hele bestanden. Er zitten nog een aantal checks ingebouwd (Bestaat username al?) en MySQL-connect natuurlijk. Mijn belangrijkste vraag, in hoeverre is mysql_real_escape_string veilig?

[Kwastie]

Gebruik pdo bindparam http://www.php.net/manual/en/pdostatement.bindparam.php

[X_lawl_X]

PHP:

//Make sessionid 
    $userpass = $_POST['username'].$_POST['password']; 
    $userpass = md5($userpass);

Gebruik je nu een hash van password + username om een sessie id te maken? Niet doen!

en wat is het nut van dit?

PHP:

 $info['password'] = $info['password'];

[Beatboxx]

@X_lawl_X

Als ik alleen de random gebruik voor t sessionid, is dat dan wel goed? En je tweede opmerking, geen idee waar dat voor dient

[X_lawl_X]

Het is inderdaad beter als je alleen een random string gebruikt. Er is geen reden waarom je login details, ge-hashed of niet, in een cookie wilt hebben.

En nog een puntje van commentaar: Ik zie dat je mysql_error() gebruikt. Is leuk voor een dev omgeving, alleen in een productie-omgeving wil je dat niet hebben!

offtopic:
En waarom gebruik je niet session_start() en session_id() ipv jouw methode? De default PHP session handler is ook niet perfect, maar wel beter als je net met login systemen gaat werken, imo. Dan hoef je je ook geen zorgen meer te maken over het genereren van een Sessie ID.

[ Voor 20% gewijzigd door X_lawl_X op 23-10-2011 16:01 ]

[Verwijderd]

Geef geen specifieke melding dat de gebruikersnaam niet gevonden is maar iets in de richting van "gebruikersnaam en wachtwoord combi niet correct" voor zowel een niet bestaande gebruiker als een fout wachtwoord. Hiermee voorkom je dat evil-script-kiddies kunnen achterhalen wat bestaande gebruikersnamen zijn.

Gebruik tevens duidelijke functie namen zoals:

function Random($length=128); -> function generateRandomSalt($length=128);

[ Voor 15% gewijzigd door Verwijderd op 23-10-2011 16:16 ]

[Manuel]

Beatboxx schreef op zondag 23 oktober 2011 @ 15:41:
Mijn belangrijkste vraag, in hoeverre is mysql_real_escape_string veilig?

Daar hoef je je geen zorgen over te maken, alles wat jij ingeeft wordt gewoon geëscaped zoals het hoort. Vergeleken met stripslashes is dit al een goede stap voorwaards. Wie weet kun je binnenkort over gaan naar PDO of MySQLi zodat het nog wat overzichtelijker kan worden. Parameterized queries zien er naar mijn mening toch beter uit dan: mysql_real_escape_string("user-input");

Verwijderd schreef op zondag 23 oktober 2011 @ 16:14:
Gebruik tevens duidelijke functie namen zoals:

function Random($length=128); -> function generateRandomSalt($length=128);

Waarom geen 'generateSalt' gebruiken, korter en even duidelijk als 'generateRandomSalt'. Als het niet random was zou het eigenlijk 'getGlobalSalt' of 'getSalt' moeten heten.

Beatboxx schreef op zondag 23 oktober 2011 @ 15:54:
@X_lawl_X

Als ik alleen de random gebruik voor t sessionid, is dat dan wel goed? En je tweede opmerking, geen idee waar dat voor dient

Maak gewoon gebruik van session_id() en session_start(), waarom steeds het wiel opnieuw proberen uit te vinden.

offtopic:
login.php zoals het nu is gaat nooit werken omdat op regel 43 een semicolon mist. [rand]Waarom zijn de functienamen in PHP wel case-sensitive terwijl variabelen dat niet zijn, lekker consistent[/rand]

[Verwijderd]

Manuel schreef op zondag 23 oktober 2011 @ 19:29:
[...]

Waarom geen 'generateSalt' gebruiken, korter en even duidelijk als 'generateRandomSalt'. Als het niet random was zou het eigenlijk 'getGlobalSalt' of 'getSalt' moeten heten.

Is inderdaad beter omdat "random" overbodig is.