[PHP] Inlogscript bij foutieve users eindigt in loop

[Verwijderd]

Geachte medetweaker,

Samen met een oom ben ik bezig met een website met daarin de mogelijkheid om in te loggen. Het inloggen werkt perfect met de juiste invoer. Ook als niet bestaande of foutieve gegevens worden opgegeven wordt dit weergeven met een melding na het klikken op de submit knop.
Echter zit daar nog een probleem waar ik niet uit kom, want wanneer er een niet bestaande gebruiker of foutieve gegevens worden opgegeven na het submitten komt de popup en beland het php script in een loop. Als er op ok wordt geklikt (popup) blijft de pagina wit.

Het script moet na die popup na een aantal seconden gewoon weer terug naar de pagina waar de gebruiker vandaan kwam. Of is het ook mogelijk om zonder refresh van de pagina al in de Database te kijken of de gegevens correct zijn?

Hier het script dat we momenteel gebruiken:

PHP:

<?php  
session_start();

$con = mysql_connect("serverip#verborgen","domein#verborgen","wachtwoord#verborgen");
if (!$con)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("domein#verborgen", $con);

if(isset($_SESSION) && $_SESSION['lastActive']>time()+60*2){ // er is een sessie en de gebruiker is in laatste 15 min actief geweest.
  $_SESSION['lastActive']=time(); // Geklikt, dus laatst actief updaten 
  header("Location: verborgen#doorverwijzing-na-login"); // Doorverwijzen naar je ingelogde pagina 
  exit; //en netjes je header sluiten 
  }//--einde van de if 
  
$wachtwoord = md5($_POST['password']);
  if(isset($_POST['klantgegevens'])){ // Er is op de loginknop gedrukt 
      if(empty($_POST['username'])){
         echo '<script language="javascript"> alert("Er is geen gebruikersnaam opgegeven") </script>';
      }else { 
         if (empty($_POST['password'])){
            echo '<script language="javascript"> alert("Er is geen wachtwoord opgegeven") </script>'; 
         }else{ //dus netjes ingevuld
            $id = mysql_query("SELECT gebruikersnaam, wachtwoord FROM Abonnees  
                  WHERE gebruikersnaam='".$_POST['username']."' AND wachtwoord='".$wachtwoord."' AND ip_adres='" .$_SERVER['REMOTE_ADDR'] ."' AND bevestiging = 2
                  LIMIT 1");    
            if(mysql_num_rows($id)==0){
                   echo '<script language="javascript"> alert("De inloggegevens zijn incorrect, denk aan de activatie van uw account!") </script> <meta http-equiv="refresh" content="2; url=domein#tijdelijke-homepage">';/// 
                }else{ 
               $_SESSION['lastActive'] = time(); // je bent actief, dus tijd opslaan 
               header("Location: verborgen#domein-na-inloggen"); // Gebruiker ingelogd nu, dus doorverwijzen naar de inlogpagina 
               exit; // en weer netjes je header sluiten  
            }//--einde wel bestaan  
         }//--einde netjes ingevuld  
      }//--einde van de if inlogsubmit
  }
mysql_close($con);
?>

[ Voor 1% gewijzigd door BtM909 op 08-02-2012 12:07 ]

[Icey]

Even snel tussendoor;

- Je script is vatbaar voor mysql injection (!!) dus ik kan mijzelf nu zonder problemen inloggen als wie dan ook.
- Je hebt een IP adres gekoppeld aan een account? Dan kan ik dus nooit inloggen met mijn dynamische ipadres, op mijn werk of mobiele telefoon!
- md5 hashes is allang niet meer veilig te noemen. Kijk eens naar sha1() en het liefst met een salt (toevoeging)
- Ik zou nog eens goed kijken naar de opbouw; javascriptjes; headers.. Allemaal niet nodig!

[Verwijderd]

Ok bedankt! Ben beginnend bezig met PHP. Hoe weet ik of wanneer is het script vatbaar voor de injection? Dan kan ik daar rekening mee houden. Thanks.

[ Voor 44% gewijzigd door Verwijderd op 06-02-2012 14:31 ]

[Struikrover]

Wat je in principe nu doet is eerst het formulier submitten, en daarna met Javascript alerten als er iets niet is ingevuld? Dat is niet echt de manier waarop je zoiets afhandelt.

Correcter zou zijn:

- Laat javascript bij een onSubmit event checken of een van de velden leeg is. Zo ja, geef een popup en verstuur het formulier niet. Dit is alleen voor de gebruikersvriendelijkheid, je kunt dit namelijk makkelijk omzeilen

- Bij het submitten van het formulier, check via PHP of een van de velden leeg is of illegale tekens bevat. Indien dit zo is, presenteer je het formulier gewoon nog een keer, met de melding op de pagina dat er een fout is opgetreden
(dit kun je doen door een redirect te doen en bijvoorbeeld een sessievariabele 'error' aan te maken, waarop je uberhaupt controleert bij het laden van het formulier. Als er fouten instaan laat je die zien, en leeg je $_SESSION['error'] o.i.d. weer)

- Indien de velden beide zijn ingevuld dien je je data nog te escapen, om te voorkomen dat er SQL injecties kunnen worden gedaan. Lees je even in in de PHP functie filter_input, deze kan dit automatisch voor je doen.

- Nu kun je checken of de gebruiker is gemachtigd door de veilige username en password waarden te checken met de database. Indien dit een fout geeft zet je de $_SESSION['error'] weer aan bijvoorbeeld, en stuur je de header weer naar de locatie van het document (dezelfde locatie kan dan ook natuurlijk).

Succes


EDIT:

Verwijderd schreef op maandag 06 februari 2012 @ 14:29:
Ok bedankt! Ben beginnend bezig met PHP. Hoe weet ik of wanneer is het script vatbaar voor de injection? Dan kan ik daar rekening mee houden. Thanks.

Altijd wanneer je je POST-variabelen direct in een MYSQL-query zet, en deze variabelen zijn ingevuld door de gebruiker, ben je vatbaar voor een SQL injectie.

Bijvoorbeeld: ik vul in beide velden in: ' OR 'a' = 'a , dan wordt je query:

code:

"SELECT gebruikersnaam, wachtwoord FROM Abonnees WHERE gebruikersnaam=' ' OR 'a' = 'a' AND wachtwoord=' ' OR 'a' = 'a' AND ip_adres='" .$_SERVER['REMOTE_ADDR'] ."' AND bevestiging = 2              LIMIT 1"

Needless to say dat je nu dus altijd toegang zult hebben.

[ Voor 21% gewijzigd door Struikrover op 06-02-2012 14:44 ]

[RobIII]

Struikrover schreef op maandag 06 februari 2012 @ 14:36:
- Bij het submitten van het formulier, check via PHP of een van de velden leeg is of illegale tekens bevat.

Neen. Niks illegale tekens. Waarom zou je een (ik noem maar wat) % of ' of $ verbieden Of je dat nou verbiedt in een wachtwoord, gebruikersnaam, postcode, who-cares: Je moet er een goede reden voor hebben. "Omdat je daarmee kans loopt op SQL injection" is nooit een goede reden. Dat een postcode geen $ kan bevatten is andere koek. Waarom een wachtwoord geen ' zou mogen bevatten is mij een raadsel.

Daarbij hoor je wachtwoorden te hashen en niet als plain-text op te slaan (wat TS overigens goed doet). Hoe die tweede ...Or 'a'='a' in jouw query terecht zou moeten komen is me dan een raadsel. Goed, in het geval van een wachtwoord kom je nog weg zonder speciale tekens te verbieden of te escapen; de hash wordt toch, meestal, een string met enkel de tekens a t/m f en 0-9 (of je moet voor andere encoding van de hash data gaan ofzo). Escapen ervan kost echter ook niets en is gewoon good practice IMHO. Maar er is ook geen reden om "speciale tekens" bijvoorbeeld te verbieden in, ik roep wat, een blog-comment of forum post. Zo kun je hier op dit forum (en -tig andere sites) toch ook rustig allerlei gekke tekens en complete queries posten zonder dat we vrezen dat je onze DB overhoop haalt?

Struikrover schreef op maandag 06 februari 2012 @ 14:36:
Lees je even in in de PHP functie filter_input, deze kan dit automatisch voor je doen.

Neen. mysql_real_escape_string (voor MySQL althans, andere RDBMS'en hebben mogelijk een andere functie zoals pg_escape_string) of nog beter: Parametrized Queries.

Struikrover schreef op maandag 06 februari 2012 @ 14:36:
Altijd wanneer je je POST-variabelen direct in een MYSQL-query zet, en deze variabelen zijn ingevuld door de gebruiker, ben je vatbaar voor een SQL injectie.

Alleen als je niet escaped. Je kunt prima een $_POST['somevar'] in je query opnemen mits 'ie escaped is (of je een parameterized query gebruikt):

PHP:

$qry = "select * from `bar` where `foobar` = '" . $_POST['somevar'] ."'"; //FOUT!
$qry = "select * from `bar` where `foobar` = '" . mysql_real_escape_string($_POST['somevar']) ."'"; //Goed

$foo = $_POST['somevar'];
$qry = "select * from `bar` where `foobar` = '" . $foo ."'"; //FOUT!
$qry = "select * from `bar` where `foobar` = '" . mysql_real_escape_string($foo) ."'"; //Goed

$_POST['somevar'] = mysql_real_escape_string($_POST['somevar']); // >> NIET DOEN <<

//Prepared statement:
$stmt = $db->prepare("select * from `bar` where `foobar` = ?");
$stmt = bind_param("s", $_POST['somevar']); //Goed, geen escaping vereist
$stmt->execute();

En ga nou alsjeblieft niet de $_POST, $_GET of weet-ik-het variabelen verkloten door ze "alvast" te escapen (zie regel 8 in mijn voorbeeld). Escapen doe je in een context; in een query gebruik je daar een escape functie voor het betreffende RDBMS voor, in HTML gebruik je daar htmlentities/htmlspecialchars voor, in een url urlencode en in een PDF of CSV of verzin-iets gebruik je de daar weer benodigde escaping.

Verwijderd schreef op maandag 06 februari 2012 @ 14:29:
Hoe weet ik of wanneer is het script vatbaar voor de injection?

Door te weten waar je 't over hebt en je dus in de materie te verdiepen

[ Voor 62% gewijzigd door RobIII op 06-02-2012 15:53 ]

[Verwijderd]

Dank mensen voor de duidelijke uitleg, die escape string heb ik vaker van gehoord, en Rob ik ga me er nu zeker in verdiepen, komt toch meer bij kijken dan ik dacht . Meer tips zijn zeker welkom.

[ Voor 35% gewijzigd door Verwijderd op 06-02-2012 15:58 ]

[Struikrover]

RobIII schreef op maandag 06 februari 2012 @ 15:21:
[...]

Neen. Niks illegale tekens. Waarom zou je een (ik noem maar wat) % of ' of $ verbieden Of je dat nou verbiedt in een wachtwoord, gebruikersnaam, postcode, who-cares: Je moet er een goede reden voor hebben. "Omdat je daarmee kans loopt op SQL injection" is nooit een goede reden. Dat een postcode geen $ kan bevatten is andere koek. Waarom een wachtwoord geen ' zou mogen bevatten is mij een raadsel.

Daarbij hoor je wachtwoorden te hashen en niet als plain-text op te slaan (wat TS overigens goed doet). Dan kom je in het geval van een wachtwoord nog weg zonder speciale tekens te verbieden (de hash wordt toch, meestal, een string met enkel de tekens a t/m f en 0-9 (of je moet voor andere encoding van de hash data gaan ofzo)). Maar er is ook geen reden om speciale tekens bijvoorbeeld te verbieden in, ik roep wat, een blog-comment. Zo kun je hier op dit forum (en -tig andere sites) toch ook rustig allerlei gekke tekens en complete queries posten zonder dat we vrezen dat je onze DB overhoop haalt?

Tsja, klopt inderdaad als een bus. Ik zat onterecht te denken in het algemene geval, bijvoorbeeld wanneer je een geldig e-mail adres ingevuld wilt hebben.
In dit geval klopt het dat je helemaal geen extra illegale tekens af te vangen...

RobIII schreef op maandag 06 februari 2012 @ 15:21:
Neen. mysql_real_escape_string (voor MySQL althans, andere RDBMS'en hebben mogelijk een andere functie zoals pg_escape_string) of nog beter: Parametrized Queries.

Wat stom . Natuurlijk moet je mysql_real_escape_string gebruiken en niet filter_input.

offtopic:
Waarom typ ik in godsnaam filter_input???

RobIII schreef op maandag 06 februari 2012 @ 15:21:
Alleen als je niet escaped. Je kunt prima een $_POST['somevar'] in je query opnemen mits 'ie escaped is (of je een parameterized query gebruikt):

Hence mijn verwoording: als je POST of GET variabelen direct in je query stopt. Direct impliceert in dit geval zonder te escapen.

Maar dank voor de terechtwijzingen . Hoop dat de TS er zo wat aan heeft!

[jessy100]

Verwijderd schreef op maandag 06 februari 2012 @ 14:29:
Ok bedankt! Ben beginnend bezig met PHP. Hoe weet ik of wanneer is het script vatbaar voor de injection? Dan kan ik daar rekening mee houden. Thanks.

ik zou gewoon slashes adden

code:

function safetext( $text='')
{
 *knip* blijkt onveilig te zijn.
}

en dan gewoon '".safetext($_POST["Variable naam"])."'

dat scheelt al een hele boel tegen SQL injecties

[ Voor 27% gewijzigd door jessy100 op 08-02-2012 16:39 ]

[Voutloos]

NEEN. Die function is het slechtste idee ooit, en waarom heb ik denk ik al in een topicje of 10 op GoT uitgelegd.

[Manuel]

jessy100 schreef op dinsdag 07 februari 2012 @ 14:52:
[...]


ik zou gewoon slashes adden

en dan gewoon '".safetext($_POST["Variable naam"])."'

dat scheelt al een hele boel tegen SQL injecties

Doe dit niet! Gebruik in plaats daarvan:

RobIII schreef op maandag 06 februari 2012 @ 15:21:
mysql_real_escape_string (voor MySQL althans, andere RDBMS'en hebben mogelijk een andere functie zoals pg_escape_string) of nog beter: Parametrized Queries.

[CodeCaster]

jessy100 schreef op dinsdag 07 februari 2012 @ 14:52:
[...]

Er bestaat niet één magische functies om alle soorten tekst "veilig" te maken. Dat hebben ze bij PHP sinds versie 4 en nog een beetje ook ingezien, en daarom juist alles wat jij nu doet standaard uitgeschakeld.

Met het toevoegen van slashes ben je er nog lang niet als je bijvoorbeeld queries aan het opbouwen bent, en strippen van tags doe je alleen als je die tekst weer als HTML gaat outputten.

[Cartman!]

jessy100 schreef op dinsdag 07 februari 2012 @ 14:52:
dat scheelt al een hele boel tegen SQL injecties

je wilt niet 'een hele boel', je wilt helemaal... als het om veiligheid gaat graag geen halfbakken oplossing aanbieden En strip_tags is zo'n beetje de domste manier van uitbreken van code... ook niet gebruiken dus (!).

[Struikrover]

Het mooie van mysql_real_escape_string is ook dat je code precies zo in de database komt te staan als je hem hebt ingevoerd. Je hoeft helemaal niet moeilijk te doen met encoding en HTML-entities. Het enige dat je doet is zorgen dat alle karakters die eventueel je SQL query zouden kunnen beïnvloeden ge-escaped worden, maar uiteindelijk wel weer origineel in de database komen te staan.

[YopY]

Ik ben van mening dat als er weer eens een PHP hulptopic geopend wordt dat openstaat voor SQL injection, mysql_real_escape_string niet of nauwelijks genoemd wordt, en prepared statements als standaardoplossing voor het bouwen en uitvoeren van queries wordt aangeboden.

Vindt het wel grappig dat dit soort topics overigens altijd over SQL injectie ipv de daadwerkelijke vraag gaan, . Niet verkeerd natuurlijk, maar het valt op.

[Ventieldopje]

YopY schreef op woensdag 08 februari 2012 @ 10:20:
Ik ben van mening dat als er weer eens een PHP hulptopic geopend wordt dat openstaat voor SQL injection, mysql_real_escape_string niet of nauwelijks genoemd wordt, en prepared statements als standaardoplossing voor het bouwen en uitvoeren van queries wordt aangeboden.

Vindt het wel grappig dat dit soort topics overigens altijd over SQL injectie ipv de daadwerkelijke vraag gaan, . Niet verkeerd natuurlijk, maar het valt op.

Ben ik het met je eens, het scheelt echter een hoop problemen als je belangrijke dingen zoals databases goed aan pakt, iets met slechte gewoontes zijn moeilijk af te leren Eerst leren hoe je goed moet communiceren met de database en dan pas het probleem aan pakken, zelfs een kans dat je probleem al opgelost wordt door de kennis die je op doet in het proces

Zou wel handig zijn als er een soort FAQ hier op tweakers.net komt zodat we daar naar toe kunnen linken in plaats van altijd het zelfde uit te leggen

[ Voor 7% gewijzigd door Ventieldopje op 08-02-2012 10:24 ]

[Verwijderd]

Ventieldopje schreef op woensdag 08 februari 2012 @ 10:24:
[...]

Zou wel handig zijn als er een soort FAQ hier op tweakers.net komt zodat we daar naar toe kunnen linken in plaats van altijd het zelfde uit te leggen

Deze?

[jessy100]

Cartman! schreef op dinsdag 07 februari 2012 @ 15:03:
[...]

je wilt niet 'een hele boel', je wilt helemaal... als het om veiligheid gaat graag geen halfbakken oplossing aanbieden En strip_tags is zo'n beetje de domste manier van uitbreken van code... ook niet gebruiken dus (!).

ja, dit is mij aangeprezen als de beste optie, door mijn leraar nota bene. tijd dat die man weer eens op cursus gaat.

[Wokkels]

Even terug om ook de originele vraag te beantwoorden:

PHP:

$wachtwoord = md5($_POST['password']);
  if(isset($_POST['klantgegevens'])){ // Er is op de loginknop gedrukt 
      if(empty($_POST['username'])){
         echo '<script language="javascript"> alert("Er is geen gebruikersnaam opgegeven") </script>';
      }else { 
         if (empty($_POST['password'])){
            echo '<script language="javascript"> alert("Er is geen wachtwoord opgegeven") </script>'; 
         }else{ 
      
          [...]
  
         }//--einde netjes ingevuld  
      }//--einde van de if inlogsubmit
  }
mysql_close($con);
?>

In de quote hierboven heb ik wat irrelevante code weggelaten en je if/else even versimpeld, zodat je kunt zien dat, indien er een van beide velden niet is ingevuld, er een popup wordt weergegeven, vervolgens breekt php uit de if/else en gaat hij naar "//--einde netjes ingevuld " in de code. Er gebeurt daarna niets meer. Je script belandt dus niet in een loop, maar doet precies hoe het is gemaakt. Na de popup wordt er niets meer geoutput.

[Cartman!]

Wellicht een beetje offtopic maar mysql_close heb je in principe nooit nodig, dat regelt php zelf voor je

[Verwijderd]

jessy100 schreef op woensdag 08 februari 2012 @ 16:39:
[...]


ja, dit is mij aangeprezen als de beste optie, door mijn leraar nota bene. tijd dat die man weer eens op cursus gaat.

Jemig ... ik moet ook maar eens les gaan geven dan ...

Cartman! schreef op woensdag 08 februari 2012 @ 20:01:
Wellicht een beetje offtopic maar mysql_close heb je in principe nooit nodig, dat regelt php zelf voor je

Maar het is wel zo netjes, dus laat iedereen het aub aanleren ...

[ Voor 33% gewijzigd door Verwijderd op 08-02-2012 20:24 ]

[Beatboxx]

Verwijderd schreef op woensdag 08 februari 2012 @ 20:22:
[...]


Maar het is wel zo netjes, dus laat iedereen het aub aanleren ...

omdat? Werkt de code anders minder goed? Minder snel?

[RobIII]

Beatboxx schreef op woensdag 08 februari 2012 @ 20:35:
[...]


omdat? Werkt de code anders minder goed? Minder snel?

Het zijn gewoon zaken die bepaalde mensen als "best practice" beschouwen en anderen als "let the <insert_something_here> handle it" (waarbij je dus kunt denken aan de interpreter, framework, OS, who-cares).

In veel zaken ben ik ook graag (erg) expliciet in mijn code; daarbij: als ik iets niet meer nodig heb kan ik 't laten rondslingeren tot ik er mee klaar ben of ik kan 't opruimen en de resources vrijmaken voor andere (concurrent/whatever) users/processen/etc. Of ik 't in dit geval zou doen weet ik niet, maar ik vermoed dat ik dat sowieso in mijn DAL zou doen; de connectie gaat toch terug in de connectionpool en is net zo snel weer open.

Maar dit wordt een holy war die hetzelfde gevochten zal worden als XHTML vs. HTML, == vs ===, implicit casts vs. explicit casts en ga zo maar door. Laat lekker ieder voor zichzelf beslissen. Ik zelf kies graag voor expliciet omdat ik daarmee niet hoef te vertrouwen op aannames. Bijvoorbeeld: je kunt een Decimal.Parse een string "5,00" voeren en dat gaat prima zolang je op een nl-NL locale draait; toch geef ik dan liever een IFormatprovider mee als ik wéét dat de string een komma gaat bevatten als decimaalscheidingsteken.

[Cartman!]

Als er verwarring kan ontstaan is expliciet werken vrij logisch ja maar bij PHP staat in de handleiding dat het gewoon niet nodig is:

Using mysql_close() isn't usually necessary, as non-persistent open links are automatically closed at the end of the script's execution. See also freeing resources.

en

Thanks to the reference-counting system introduced with PHP 4's Zend Engine, a resource with no more references to it is detected automatically, and it is freed by the garbage collector. For this reason, it is rarely necessary to free the memory manually.

Dus tenzij je er een reden voor hebt gewoon lekker PHP z'n werk laten doen, kan er alleen maar minder misgaan.

[RobIII]

Zonder de daadwerkelijke pagina erbij gepakt te hebben:

Using mysql_close() isn't usually necessary, as non-persistent open links are automatically closed at the end of the script's execution. See also freeing resources.

Dat is voor mij iig reden om even verder te lezen.

Thanks to the reference-counting system introduced with PHP 4's Zend Engine, a resource with no more references to it is detected automatically, and it is freed by the garbage collector. For this reason, it is rarely necessary to free the memory manually.

Als ik de GC kan helpen door expliciet aan te geven dat ik een resource niet meer nodig heb (en de GC dus eerder z'n werk kan doen, als 'ie het dan überhaupt nog moet doen) dan is dat niet verkeerd IMHO.

Neemt overigens niet weg dat ik er op vertrouw dat de GC z'n werk prima doet, maar als ik een script/programma heb dat bij start een DB-connectie nodig heeft, wat leest, en vervolgens (bij wijze van) drie kwartier gaat staan rekenen met die data zonder de DB-connectie nog nodig te hebben dan ruim ik 'm op. Voor een gemiddeld PHP script dat toch "short-lived" is boeit 't inderdaad niet, maar schaadt 't ook niet als je 't wél doet. Stop je zoiets in je DAL dan merk je 't niet eens.

Daarbij hangt 't ook af van welk type resource (een DB-connectie zal ik sneller laten "rondslingeren" dan, zeg, een huge-ass (in-memory) bitmap object dat ik niet meer nodig heb), de (verwachtte) load, het systeem, het totaalplaatje etc.

Maar goed; as said: ieder z'n ding. Ikzelf ben van de explicietjes, een ander weer niet. Allebei prima, toch?

[ Voor 11% gewijzigd door RobIII op 08-02-2012 21:02 ]

[Cartman!]

RobIII schreef op woensdag 08 februari 2012 @ 20:59:
Zonder de daadwerkelijke pagina erbij gepakt te hebben:
[...]
Dat is voor mij iig reden om even verder te lezen.
[...]
Als ik de GC kan helpen door expliciet aan te geven dat ik een resource niet meer nodig heb (en de GC dus eerder z'n werk kan doen, als 'ie het dan überhaupt nog moet doen) dan is dat niet verkeerd IMHO.

Verkeerd is het niet, maar het is in 99,9% van de gevallen gewoon loos.

Neemt overigens niet weg dat ik er op vertrouw dat de GC z'n werk prima doet, maar als ik een script/programma heb dat bij start een DB-connectie nodig heeft, wat leest, en vervolgens (bij wijze van) drie kwartier gaat staan rekenen met die data zonder de DB-connectie nog nodig te hebben dan ruim ik 'm op.

Uiteraard

Voor een gemiddeld PHP script dat toch "short-lived" is boeit 't inderdaad niet, maar schaadt 't ook niet als je 't wél doet. Stop je zoiets in je DAL dan merk je 't niet eens.

Dat klopt, maar de TS gebruikt geen DAL en gezien zijn wat voor dingen hij maakt is het gewoon compleet overbodig nu, hij kan er enkel fouten in maken zegmaar

Daarbij hangt 't ook af van welk type resource (een DB-connectie zal ik sneller laten "rondslingeren" dan, zeg, een huge-ass (in-memory) bitmap object dat ik niet meer nodig heb), de (verwachtte) load, het systeem, het totaalplaatje etc.

Maar goed; as said: ieder z'n ding. Ikzelf ben van de explicietjes, een ander weer niet. Allebei prima, toch?

Ieder z'n ding ja, ik ben ook vrij expliciet aangelegd maar iets wat automatisch goed gaat ga ik niet aan rommelen als het geen winst oplevert

[Beatboxx]

Verder is md5 hopeloos ouderwets, gebruik liever bcrypt. Als je database gehackt mocht worden ligt bij md5 zo'n 85% van je wachtwoorden 'plain-text' op straat, aangezien die in rainbow-tables zitten. Bij bcrypt kost het veel, heel veel tijd om de wachtwoorden te achterhalen. Dus 100000en malen veiliger!

Als je de hash van het wachtwoord wilt maken, dus tijdens het registreren of wijzigen van wachtwoord (zorg er wel voor dat het bestand bcrypt.php in dezelfde map staat:

PHP:

require_once('bcrypt.php');
$bcrypt = new Bcrypt(13);
$hash = $bcrypt->hash($hetwachtwoord);

En als je tijdens inloggen het wachtwoord wilt checken:

PHP:

require_once('bcrypt.php');
$bcrypt = new Bcrypt(13);
$logincheck = $bcrypt->verify($userinput, $hash);
if($logincheck === true){
echo 'membercontent';
}
if($logincheck === false){
echo 'Het wachtwoord klopt niet!';
}

Met die 13 kan je spelen, hoe hoger het getal hoe langer brute-forcen duurt, maar ook hoe langer inloggen duurt.

Heb 'm niet getest, er kunnen bugs in zitten!

[ Voor 12% gewijzigd door Beatboxx op 09-02-2012 20:54 ]

[RobIII]

Beatboxx schreef op donderdag 09 februari 2012 @ 20:53:
Als je database gehackt mocht worden ligt bij md5 zo'n 85% van je wachtwoorden 'plain-text' op straat, aangezien die in rainbow-tables zitten.

Daar hebben we salts voor; dan zijn je rainbowtables nutteloos en kom je iig al aan 't brute-forcen of naar collisions aan 't zoeken wil je nog iets met zo'n hash kunnen. PBKDF2 of bcrypt zijn wél betere alternatieven, dat is waar. Ik zou wel oppassen met 't "blind copy/pasten" van zaken op pastebin. Zorg in ieder geval dat je snapt wat er gebeurt of zoek een betrouwbare bron. Encryptie is een gecompliceerde zaak en er hoeft maar 1 gare PRNG gebruikt te worden of een ander detail mis te zijn en je bent potentieel net zo vulnerable als wanneer je zaken plaint-text op zou slaan.

[ Voor 14% gewijzigd door RobIII op 09-02-2012 21:10 ]

[Beatboxx]

[offtopic]@RoblllIk heb 't zelf geupload, dus ik ga er vanuit dat dat wel goed zit:)[/code]

Inderdaad, als je per user een random salt gebruikt is het heel lastig, maar dan nog met een goed clustertje doe je er miljarden per seconde (Mijn G620 doet 0,6 seconde over 1 miljoen sha hashes genereren met één vaste random salt van 30 tekens)). Dus dan is het met 6 tekens passwords nog steeds niet écht moeilijk. Bcrypt is dan - zeker met oog op de toekomst - vele malen veiliger. En ik denk niet dat een van je bezoekers gaat huilen als ze 1 seconde moeten wachten tijdens inloggen!

/me Beatboxx geeft erg veel om security

[ Voor 3% gewijzigd door Beatboxx op 09-02-2012 22:37 ]

[curvemod]

Beatboxx schreef op donderdag 09 februari 2012 @ 22:37:
[offtopic]@RoblllIk heb 't zelf geupload, dus ik ga er vanuit dat dat wel goed zit:)[/code]
/me Beatboxx geeft erg veel om security

Ben het met je eens dat bcrypt de beste oplossing is, maar ik denk binnen deze context wel wat overkill. Omdat de poster zelf nog geen hele ervaren coder is (gebaseerd op code in de OP) denk ik dat een sha1 met een goede salt voor hem voorlopig voldoende is, tenzij het heel gevoelige data is. In mijn opinie moet je in het begin ook focussen op code kwaliteit, en niet teveel focussen op het sterkste encryptie algoritme

[Onoffon]

Het kan aan mij liggen, maar volgens mij is het vatbaar zijn (of het voorkomen) van een SQL-injectie niet de vraag van de TS, ook al goed bedoeld door de behulpzame tweakers, m.i. gaan we hier weer te ver off-topic.

Ok, ok, in z'n 2e post vroeg hij het...

Of is het ook mogelijk om zonder refresh van de pagina al in de Database te kijken of de gegevens correct zijn?

Ja, dat kan met AJAX.

Tutorial w3schools
Tutorial Tizag

[ Voor 4% gewijzigd door Onoffon op 09-02-2012 23:30 ]