[PHP] BeveiligingsTips nodig

[IJnte]

Ik ben druk bezig om redelijk goed login script te maken. Nu heb ik een deel gebruik gemaakt van de ideeen van de tutorial op PhpHulp.nl. Echter heb ik zo mijn eigen code erin geprogged.

Nu ben ik natuurlijk ook druk bezig met uit te zoeken wat zoal verstandig is om te doen. Zo heb ik dit topic goed doorgelezen en zie ik een aantal slimme dingen voorbij komen.

Nu gebruik ik zowel sessies als cookies. De cookies gebruik ik om ervoor te zorgen dat de user ingelogd kan blijven als de browser al eens is afgesloten. De gebruiker kan hiervoor kiezen op het inlog form.

Wat code (hoop niet te veel ) :

PHP:

<? 
session_start(); 
ob_start();?> 
// wat html zut
<script language="JavaScript" src="md5.js"></script>
<? 
if($_SESSION['first_name'] == "" AND $_SESSION['password'] == "" AND $_SESSION['ip_address'] =="")
{
 if($_COOKIE['first_name'] == "" AND $_COOKIE['password'] == "" AND $_COOKIE['Ip_address'] == "")
 {
   if($_POST['naam'] != "" AND $_POST['ww_crypt'] != "")
   {
    //Connect om te kijken of de user + wachtwoord klopt
    require("./connect.php");
    $sql = "SELECT first_name FROM customers WHERE first_name='".$_POST['naam']."'"; 
    $resultaat = mysql_query($sql) OR die ("Kon geen verbinding maken met MySQL1"); 
    $Results = mysql_num_rows($resultaat);
     if($Results == "")
      {
      echo "De gebruikersnaam is niet bekend in ons systeem";
      }
      else{
      $sql = "SELECT password, first_name, last_name, customer_id FROM customers WHERE password='".$_POST['ww_crypt']."'"; 
      $resultaat1 = mysql_query($sql) OR die ("Kon geen verbinding maken met MySQL1"); 
      $data = mysql_fetch_array($resultaat1);
       if($data =="")
        {
        echo "Je wachtwoord is verkeerd ingevult";
        }
        else{
            echo "Hallo ".$data['first_name']." ".$data['last_name']."<br>";
            echo "Je bent ingelogt!";
            echo "<br>";
            echo "Je wordt automatisch doorverwezen naar de hoofdpagina!";
            ?>
            <SCRIPT LANGUAGE="JavaScript">setTimeout("top.location.href = '/dedicated/index.php' ",3000);</SCRIPT>
            <?
            $_SESSION['first_name'] = md5($data['first_name']);
            $_SESSION['password'] = $data['password'];
            $_SESSION['ip_address'] = md5(getenv("REMOTE_ADDR"));
            $_SESSION['customer_id'] = $data['customer_id'];
            if($_POST['ingelogd_blijven'] == "1")
             {
              $formule_hash = ((36500*495)/21);
              setcookie("first_name", md5($data['first_name']), time() + 365 * 86400); 
              setcookie("dedi-id", $data['customer_id'], time() + 365 * 86400);
              setcookie("password", $data['password'], time() + 365 * 86400);
              setcookie("Ip_address", md5(getenv("REMOTE_ADDR")), time() + 365 * 86400); 
             }
            }
    
      }
    
   }
   else{
   echo "Vul je gegevens hieronder in!";
// Het invul formulier met daarin de verwijzing naar het encrypten van het wachtwoord (zie verder in topic).

  }
 }
 else{
 //cookie controlle
  require("./connect.php");  
  $sql = "SELECT password, customer_id, first_name FROM customers WHERE password='".$_COOKIE['password']."' AND customer_id='".$_COOKIE['dedi-id']."'"; 
  $resultaat2 = mysql_query($sql) OR die ("Kon geen verbinding maken met MySQL1"); 
  $data1 = mysql_fetch_array($resultaat2);
    if($data1 == "")
    {
     echo "Je Cookie komt niet overeen met onze gegevens";
    }
    else{
     if((md5($data1['first_name']) == $_COOKIE['first_name']) AND ($data1['password'] == $_COOKIE['password']) AND (md5(getenv("REMOTE_ADDR")) == $_COOKIE['Ip_address']))
     {
      echo "Je Cookie is geaccepteerd. Veel Plezier!";
      ?>
      <SCRIPT LANGUAGE="JavaScript">setTimeout("top.location.href = '/dedicated/index.php' ",3000);</SCRIPT>
      <?
     }
     else{
     echo "Er is met de cookie geknoeid";
     }
   }
 
 
 } // end else cookie controle

}
else{
// Sessie controle
  require("./connect.php");  
  $sql = "SELECT password, customer_id, first_name FROM customers WHERE password='".$_SESSION['password']."' AND customer_id='".$_SESSION['customer_id']."'"; 
  $resultaat2 = mysql_query($sql) OR die ("Kon geen verbinding maken met MySQL1"); 
  $data1 = mysql_fetch_array($resultaat2);
    if($data1 == "")
    {
     echo "Je Sessie komt niet overeen met onze gegevens";
    }
    else{
     if((md5($data1['first_name']) == $_SESSION['first_name']) AND ($data1['password'] == $_SESSION['password']) AND (md5(getenv("REMOTE_ADDR")) == $_SESSION['ip_address']))
     {
      echo "Je Sessie is geaccepteerd. Veel Plezier!";
      ?>
      <SCRIPT LANGUAGE="JavaScript">setTimeout("top.location.href = '/dedicated/index.php' ",3000);</SCRIPT>
      <?
     }
     else{
     echo "Er is met de sessie geknoeid";
     }
   }


}  
?>

In het HTML formulier staat de volgende code voor de MD5 codering:

PHP:

<form method="post" action="<? echo $_SERVER['PHPSELF']; ?>" onSubmit="this.ww_crypt.value = hex_md5(this.wachtwoord.value);this.wachtwoord.value = ''"> 

Ik gebruik dit javascriptje om ervoor te zorgen dat het wachtwoord niet plain-text over het internet wordt gestuurd. In mijn database staat dit wachtwoord ook als MD5.

Wat ik begrijp wat ik ZEKER nog moet doen is gebruik maken van addslashes() in php. Ik begrijp waarom dit nodig is aan de hand van het voorbeeld in de FAQ. Ook moet ik nog alle meldingen aanpassen omdat het zo wel gemakkelijk is om uit te vogelen wat mijn username is. Dus daar moet je niet op letten

Nu vraag ik me af of mijn beveiliging zo lek is als een mandje of dat het een goed script is.
Ook vraag ik me af of de cookie die ik genereer wel veilig genoeg is. De volgende gegevens staan er namelijk in

• MD5(First_Name).
• MD5(Password).
• Dedi-id (soort customer ID), niet MD5.
• MD5(Ip_Addres).

Mijn Vraag
Wie kan me nog wat tips geven of wat hints die belangrijk zijn voor de beveiliging van mijn site

[ Voor 13% gewijzigd door IJnte op 17-05-2005 23:18 ]

[froggie]

Ik zou persoonlijk dat automatisch inloggen mbv een cookie schrappen. Wanneer iemand dat cookie te pakken kan krijgen is ie automatisch ingelogd. Al je werk om een degelijk script te produceren is dan meteen voor niets.

Een nettere methode is om user unieke data bij te houden in een sessie en deze steeds vergelijken met de actuele data. Je zou bijv het ip adres, de login timestamp, een of ander random gegenereerd getal en de user agent string mbv MD5 in een cookie kunnen stoppen en op iedere pagina de hash van de actuele data vergelijken met die uit het cookie. Zodra de twee hashes ongelijk zijn kun je meteen de sessie afschieten.
Het cookie met de data kun je een beperkte levensduur geven en iedere zoveel tijd (zeg ieder half uur, of ieder uur) zou ik de user z'n password nog een keer laten intikken. Het is misschien wat onhandig voor de gebruiker maar op die manier beperk je de risico's.

[ Voor 9% gewijzigd door froggie op 17-05-2005 23:39 . Reden: Typo's ]

[ludo]

In het HTML formulier staat de volgende code voor de MD5 codering:

PHP:

<form method="post" action="<? echo $_SERVER['PHPSELF']; ?>" onSubmit="this.ww_crypt.value = hex_md5(this.wachtwoord.value);this.wachtwoord.value = ''"> 

Volgens mij moet het PHP_SELF zijn

In mijn database staat dit wachtwoord ook als MD5.

...

• MD5(Password).

Mijn Vraag
Wie kan me nog wat tips geven of wat hints die belangrijk zijn voor de beveiliging van mijn site

Om te beginnen, waarom sla je het password op in een cookie? Heeft dat werkelijk nut? In 100,01% van de gevallen nl. niet. Je beveiliging is nu inderdaad zo lek als een mandje Je slaat het password geMD5t op in je db? En je stuurt exact dezelfde informatie naar de client? Als iemand dat cookie onderschept heeft hij waarschijnlijk alles om zonder veel moeite in te loggen op je website

Misschien is het interessant om nog wat te zoeken over challenge-response systemen. Hiermee kun je een redelijk veilig authenticatie systeem maken. Verder heb ik je code niet grondig geanalyseerd, dus misschien zit er nog wel meer in Lees ook even het PHP gedeelte in de Faq van dit subforum, hier staan een aantal tips in om je website te beveiligen. Verder is er nog een heleboel over te vinden op GoT en google.

[ Voor 8% gewijzigd door ludo op 17-05-2005 23:35 ]

[MrBarBarian]

Sowieso moet je geen onderscheid maken tussen een verkeerde username of een verkeerd password..

Als ik je site wil hacken, en ik krijg de melding dat ik een verkeerd password heb ingevult, weet ik iig zeker dat ik een goedr username gebruik..

Oh, en er staan hopelijk geen passwords in de database, maar een hash hiervan?

_{ik moet dus leren lezen.. maar als je dat van je username/pass aanpast wordt je code direct een stuk korter en eenvoudiger.. lijkt me wel makkelijk om snel te doen dus}

[ Voor 24% gewijzigd door MrBarBarian op 17-05-2005 23:46 ]

[IJnte]

MrBarBarian schreef op dinsdag 17 mei 2005 @ 23:38:
Sowieso moet je geen onderscheid maken tussen een verkeerde username of een verkeerd password..

Als ik je site wil hacken, en ik krijg de melding dat ik een verkeerd password heb ingevult, weet ik iig zeker dat ik een goedr username gebruik..

Oh, en er staan hopelijk geen passwords in de database, maar een hash hiervan?

Yup. Als je mijn verhaal eronder en erboven gelezen hebt (goed) dan zie je dat ik hem met MD5 in de database heb gezet . Ook zei ik in mijn text dat ik de meldingen nog MOET aanpassen. Dit heb ik dus nog niet gedaan . Voor mij is het dus een manier om te testen of alles goed gaat

Euh wat betreft een Unieke waarde in de Cookie heb ik met MD5 de gebruikes zijn IP adres opgeslagen in de cookie. Dus dat is zowieso uniek omdat ie controlleerd met md5(getenv("REMOTE_ADDR")) of zijn IP gelijk is aan het MD5 IP in de cookie / Sessie. Is dit nog niet uniek genoeg Mijn cookie bestaat dus uit een hele hoop strings van 25 getallen/letters. Kan je dan zomaar die MD5 beveiliging omzeilen / kraken

Wat betreft dat challenge response systeem, ik zou eerlijk gezegd niet weten hoe ik dat netjes moet maken Ik neem aan dat ik een soort hash moet maken van de tijd en b.v. het IP, maar hoe kan ik dat dan vergelijken op het moment dat de user inlogt met zijn "cookie" Je tijd is dan anders, dus je zou hem moeten vergelijken met een soort tijdverschill oid

[Edit]
Ik zie de edit van MrBarBarian. Ik ga dit ook zeker doen. Het is puur voor mij om te kijken of het script doet wat ie moet doen met al die if statements. Ik probeer wel zoveelmogelijk beveiliging erin te houden door dingen dubbel te controlleren. Ik ben dus zeker met je eens dat ik die meldingen moet vervangen door 1 standaard melding: "Je gebruikersnaam of wachtwoord is incorrect". Ook wil ik er een soort van "maximaal aantal pogingen" aan vast plakken. Maar dat is voor later

[ Voor 21% gewijzigd door IJnte op 17-05-2005 23:50 . Reden: reactie op edit MrBarBarian ]

[crisp]

1) sla geen gebruikersgegevens op in een cookie; dat hoort in je DB thuis en nergens anders
2) sla geen wachtwoord op in een cookie; ook geen MD5 hash als daarmee direct in te loggen is (wat in dit geval zo is). Gebruik gewoon een uniek gegenereerde sessie-id.
3) stuur geen data over de lijn waarmee iemand anders ook zo kan inloggen. Gebruik dus een challenge-response systeem
4) het locken van een sessie aan een IP is een goed idee; bedenk echter dat dit niet voor iedereen mogelijk is (dynamische ip's) - geef de gebruiker dus de mogelijkheid om daarvoor te kiezen
5) geef de gebruiker ook de mogelijkheid om zelf te bepalen hoelang een sessie geldig is. Als ik ergens in een internetcafe inlog zou ik dan bijvoorbeeld ervoor kunnen kiezen dat mijn sessie al vrij snel expired - voor het geval ik zelf vergeet uit te loggen
6) bouw mogelijkheden in waarmee gebruikers zelf hun sessies kunnen bekijken en beheren. informatie zoals ip-adres en user agent zijn daarbij handig
7) bouw logging in zodat je bij vermeend misbruik informatie achter de hand hebt.

[IJnte]

crisp schreef op dinsdag 17 mei 2005 @ 23:51:
1) sla geen gebruikersgegevens op in een cookie; dat hoort in je DB thuis en nergens anders
2) sla geen wachtwoord op in een cookie; ook geen MD5 hash als daarmee direct in te loggen is (wat in dit geval zo is). Gebruik gewoon een uniek gegenereerde sessie-id.
3) stuur geen data over de lijn waarmee iemand anders ook zo kan inloggen. Gebruik dus een challenge-response systeem
4) het locken van een sessie aan een IP is een goed idee; bedenk echter dat dit niet voor iedereen mogelijk is (dynamische ip's) - geef de gebruiker dus de mogelijkheid om daarvoor te kiezen
5) geef de gebruiker ook de mogelijkheid om zelf te bepalen hoelang een sessie geldig is. Als ik ergens in een internetcafe inlog zou ik dan bijvoorbeeld ervoor kunnen kiezen dat mijn sessie al vrij snel expired - voor het geval ik zelf vergeet uit te loggen
6) bouw mogelijkheden in waarmee gebruikers zelf hun sessies kunnen bekijken en beheren. informatie zoals ip-adres en user agent zijn daarbij handig
7) bouw logging in zodat je bij vermeend misbruik informatie achter de hand hebt.

Punt 1: Heb je gelijk in, echter mij ontbreekt nog de ervaring/kennis om een challange-response systeem te maken .
Punt 2: Mmm, dit is toch de gemakkelijkste en denk ik duidelijkste manier om een login te valideren.
Punt 3: Ik denk niet dat iemand kan inloggen als ie mijn cookie onderschept, omdat het IP adres uniek is.
Punt 4: Mm tja het is niet zo dat een IP adres om te 20 min verandert. Het wordt iig geen site zoals T.net waar je uren op kan rondstruinen .
Punt 5: Owk true! Ik ga daarvoor op onderzoek uit!.
Punt 6: Luxe , heeft geen prioriteit maar is inderdaad wel slim.
Punt 7: 100% mee eens!

Bedankt voor je reactie! Meer Tips zijn welkom natuurlijk .

[2mb]

Interessant topic dit, bedankt iedereen voor de goede uitleg. Ik zal morgen eens kijken naar mijn eigen code, voornamelijk asp, en kijken of ik nog wat kan bijdragen

Edit: Wat ik nu nog zo bedenk is dat het misschien wel handig is om een soort van vertraging tussen het inloggen vanaf een bepaald ip-adres in te bouwen, op deze manier ben je wat beter beschermt tegen brute-force aanvallen (die nog steeds erg populair zijn) met enorme woordenlijsten.

[ Voor 49% gewijzigd door 2mb op 18-05-2005 00:10 ]

[IJnte]

2mb schreef op woensdag 18 mei 2005 @ 00:05:
Interessant topic dit, bedankt iedereen voor de goede uitleg. Ik zal morgen eens kijken naar mijn eigen code, voornamelijk asp, en kijken of ik nog wat kan bijdragen

Edit: Wat ik nu nog zo bedenk is dat het misschien wel handig is om een soort van vertraging tussen het inloggen vanaf een bepaald ip-adres in te bouwen, op deze manier ben je wat beter beschermt tegen brute-force aanvallen (die nog steeds erg populair zijn) met enorme woordenlijsten.

Dat zou idd best een slimme optie zijn. Echter ik wil zowieso niet te veel javascript gaan gebruiken, omdat ik daar simpelweg geen kaas van gegeten heb. Ik wil het zoveel mogelijk met PHP/Html gaan maken, en tot nu toe lukt me dat aardig . Maar ik geef toe het is wel een slim idee!
Komt ook weer op het "ToDo" lijstje te staan

offtopic:
Ik ga nu pitten , morgen weer om 5:00 op (misschien iets later )

[X-Lars]

Het lijkt mij wel aardig om binnenkort (als ik tijd heb) eens een (simpele) beveiligde login pagina te maken waarin alle 'best practices' verwerkt zijn. Uiteraard met alle code. Zodat iedereen dat kan bekijken of als basis kan gebruiken voor zijn eigen website. Of misschien heeft iemand dat toevallig al?

[crisp]

IJnte schreef op dinsdag 17 mei 2005 @ 23:57:
[...]

Punt 1: Heb je gelijk in, echter mij ontbreekt nog de ervaring/kennis om een challange-response systeem te maken .

kom ik zo op terug

Punt 2: Mmm, dit is toch de gemakkelijkste en denk ik duidelijkste manier om een login te valideren.

makkelijkst is niet altijd het beste. Vanuit een MD5 is vaak met brute-force of een dictionary attack wel weer een wachtwoord te toveren. Dat is iets wat je dus intern wilt houden.

Punt 3: Ik denk niet dat iemand kan inloggen als ie mijn cookie onderschept, omdat het IP adres uniek is.

Een IP-adres hoeft niet uniek te zijn voor 1 gebruiker; denk aan proxies, meerdere pc's in een netwerk achter NAT en meerdere gebruikers die dezelfde PC sharen.

Punt 4: Mm tja het is niet zo dat een IP adres om te 20 min verandert. Het wordt iig geen site zoals T.net waar je uren op kan rondstruinen .

Dan is een mechanisme dat sessies na x minuten automatisch invalideerd sowieso handig. Neem gewoon een TTD (time to die) op in je sessietable, en als er een request komt voor die sessie na de TTD dan kill je 'm. Ook regelmatig met een cronjob opschonen uiteraard.

Punt 6: Luxe , heeft geen prioriteit maar is inderdaad wel slim.

Als je inderdaad geen blijvende logins hebt dan is dat inderdaad een luxe. In het geval je wel blijvende logins hebt dan is het imho een must. Als ik thuiskom en me bedenk dat ik ergens anders vergeten ben uit te loggen dan wil ik dat wel graag vanuit een andere sessie kunnen doen.

Bedankt voor je reactie! Meer Tips zijn welkom natuurlijk .

ok, challenge-response dus

Ik ga dus uit van een sessietabel die er ongeveer zo uit kan zien:
- sessieid (bijvoorbeeld gegenereerd dmv een md5 van een unique_id) - primary key
- userid (default 0 = geen ingelogde user)
- IP (spreekt voor zich)
- fix_to_ip (keuze om op IP te checken)
- useragent (gewoon handig om te hebben; gebruikers kunnen daaraan soms bepaalde sessie herkennen)
- TTD (standaard huidige tijd + x minuten; genoeg om in te kunnen loggen)

Gaan we uit van een niet-ingelogde gebruiker die wil inloggen

Stap 1) Genereer een sessieid en sla die op in je sessietabel met userid = 0
Stap 2) Neem deze sessieid op in een hidden veld in je formulier als challenge
Stap 3) Gebruiker vult gebruikersnaam en wachtwoord in
Stap 4) Genereer een response dmv md5(md5(wachtwoord) + gebruikersnaam + sessieid)
Stap 5) Stuur username, sessieid en response terug (+ eventuele andere opties)
Stap 6) Controleer of de sessieid voorkomt in je sessietabel, de TTD niet verstreken is en deze toebehoort aan userid 0 (geen user)
Stap 7) Controleer of de gebruikersnaam bestaat in je DB
Stap Zo ja, haal zijn md5'ed wachtwoord op uit je database
Stap 9) Genereer ook serverside de md5(md5'ed wachtwoord + gebruikersnaam + sessieid)
Stap 10) Vergelijk dit resultaat met de response van de client
Stap 11) Indien matched: gooi oorspronkelijke sessieid weg
Stap 12) Genereer een nieuwe sessieid en sla die op in je sessietabel met het juiste userid (+ andere opties)
Stap 13) Stuur een cookie met het nieuwe sessieid daarin

In alle gevallen dat er geen match is: gooi sessieid weg, en begin weer bij stap 1

Voor al je pagina's moet je nu het volgende doen:

1) Kijken of er een cookie is met een sessieid
2) Kijken of die sessieid voorkomt in de sessietabel en de TTD niet verstreken is (en IP eventueel klopt)
3) De userid ophalen uit die sessietabel
4) Daarmee de rest van de gebruikersgegevens ophalen en in een sessieobject stoppen

Note dat dit hele systeem dus geen gebruik maakt van de built-in sessies van PHP, maar puur gebruik maakt van een eigen sessietabel en cookies. Misschien niet 100% bruikbaar voor je, maar je kan er misschien wat ideeen uit halen

[2mb]

IJnte schreef op woensdag 18 mei 2005 @ 00:15:
[...]

Dat zou idd best een slimme optie zijn. Echter ik wil zowieso niet te veel javascript gaan gebruiken, omdat ik daar simpelweg geen kaas van gegeten heb. Ik wil het zoveel mogelijk met PHP/Html gaan maken, en tot nu toe lukt me dat aardig . Maar ik geef toe het is wel een slim idee!
Komt ook weer op het "ToDo" lijstje te staan

Ik zou helemaal geen JavaScript gebruiken, en zeker niet hiervoor want dat is te omzeilen aan de clientside. Ik denk meer aan iedere inlogpoging met ip + tijd opslaan in een database en dan bij een nieuwe poging het tijdverschil bekijken. Ze kun je bijvoorbeeld minimaal 1 minuut tussen de inlogpogingen zetten, en daarmee maak je brute-force met z'n tientallen pogingen per seconde (al is het dan via proxy) totaal onbruikbaar.

[T-MOB]

IJnte schreef op dinsdag 17 mei 2005 @ 23:57:
[...]
Punt 2: Mmm, dit is toch de gemakkelijkste en denk ik duidelijkste manier om een login te valideren.

Dat is wel makkelijk, idd. Maar de manier waarop je het nu geregeld hebt is het nogal onzinnig. Een hacker die een cookie met de naam 'Ip_address' tegenkomt zal erg snel snappen dat ie er een md5 hash van zijn eigen ip in moet zetten...
Als je niet van plan bent om een ingewikkeld challenge-response systeem op te zetten (zoals ik ), dan kun je de boel veiliger maken door het (gehashte) wachtwoord en het ip in keer te hashen. Met de volgende user tabel:

code:

| userid | username | password
-------------------------------
| (int)  | naam     | md5(pass)

Maak je bijvoorbeeld de volgende cookiestring:

PHP:

$cookiestring = sha1($_SERVER["REMOTE_ADDR"] .$row['password']) .$row['userid'];

Op het moment dat op iemand op je site komt dan achterhaal je het userid met een substr() op het userid gedeelte van de cookiestring en creëer je de string op nieuw met gegevens uit de database. Matchen en klaar is Klara

[crisp]

2mb schreef op woensdag 18 mei 2005 @ 00:23:
[...]

Ik zou helemaal geen JavaScript gebruiken, en zeker niet hiervoor want dat is te omzeilen aan de clientside. Ik denk meer aan iedere inlogpoging met ip + tijd opslaan in een database en dan bij een nieuwe poging het tijdverschil bekijken. Ze kun je bijvoorbeeld minimaal 1 minuut tussen de inlogpogingen zetten, en daarmee maak je brute-force met z'n tientallen pogingen per seconde (al is het dan via proxy) totaal onbruikbaar.

Javascript gebruiken om een wachtwoord te versleutelen is helemaal niet verkeerd, en hoe zou je dat willen omzeilen? Je moet alleen zorgen dat er ook een manier is om onversleuteld in te loggen voor die clients die geen javascript ondersteunen of uit hebben staan. Het wordt dan puur gebruikt als extra beveiliging tegen 'man-in-the-middle' attacks; immers vanuit de response is geen wachtwoord (of zelfs maar een md5 van het wachtwoord) te halen, en de challenge is altijd eenmalig.
vwb brute-force attacks is logging dus noodzakelijk, en de mogelijkheid om bepaalde IP's (tijdelijk) uit te sluiten. Daar zou ik echter een seperaat mechanisme voor bouwen.

Brute-force bij een challenge-mechanisme wordt ook een stuk lastiger aangezien je wel elke keer een nieuwe challenge op moet halen (kost tijd). Je kan natuurlijk ook nog een sleep() inbouwen serverside, maar bedenk daarbij dat hierdoor je de threads onnodig ophoud wat de algemene performance van je systeem kan verminderen.

[Gomez12]

crisp schreef op woensdag 18 mei 2005 @ 00:32:
[...]

Brute-force bij een challenge-mechanisme wordt ook een stuk lastiger aangezien je wel elke keer een nieuwe challenge op moet halen (kost tijd). Je kan natuurlijk ook nog een sleep() inbouwen serverside, maar bedenk daarbij dat hierdoor je de threads onnodig ophoud wat de algemene performance van je systeem kan verminderen.

Simpele gedachte, per ip bijhouden wanneer laatste challenge is opgehaald en dan max 1 challenge per 3 sec toestaan. Indien iemand sneller doet dan gewoon foutmelding met javascript timer / redirect naar de nieuwe inlog pagina. Kan iemand gaan brute-forcen met 20 per minuut, dan hoop ik toch wel dat je hem ergens signaleert voor hij bij de 1.000.000 challenges is

[TeasingU]

Misschien niet ontopic maar toch post ik het even:

Er is een speciale website opgericht door php experts dat gericht is op php en veiligheid/beveiliging
De link: http://www.phpsec.org/

Wie weet heb je er wat aan.

[Sybr_E-N]

IJnte schreef op dinsdag 17 mei 2005 @ 23:14:
Mijn Vraag
Wie kan me nog wat tips geven of wat hints die belangrijk zijn voor de beveiliging van mijn site

In de P&W FAQ staat ook het een en ander over veiligheid en beveiliging van webapplicaties.

Een ander punt is dat je zomaar, zonder te controleren, gebruikersinformatie direct in je SQL-query opneemt. Ook dat neemt een risico met zich mee namelijk, SQL Injection en XSS (Cross Site Scripting). Oplossingen en best practices daarvoor in PHP kun met deze woorden wel vinden op Google.

gebruik maken van addslashes() in php

Kijk een naar de functie, mysql_real_escape_string()

[IJnte]

Bedankt voor de reacties!!!

Ik kan niet iedereen quoten maar zal even wat reactie geven:

@ Crisp:

Punt 3:
Een IP-adres hoeft niet uniek te zijn voor 1 gebruiker; denk aan proxies, meerdere pc's in een netwerk achter NAT en meerdere gebruikers die dezelfde PC sharen.

Idd ook niet over nagedacht. Zelfde geld overigens wat T-MOB zei:

Een hacker die een cookie met de naam 'Ip_address' tegenkomt zal erg snel snappen dat ie er een md5 hash van zijn eigen ip in moet zetten...

Daar kan ik me alleen maar bij aansluiten. Ook weer gewoon niet over nagedacht! .

Wat betreft het gebruik van Javascript: Ik wil dit toch blijven gebruiken. Pech gehad voor de mensen die geen Javascript hebben aanstaan, want dat zijn ("I Quote"): "Mensen die de computer-idee lezen" (No offence!). Het bied voor mij net iets meer zekerheid dat het password niet plain-text over de lijn wordt gestuurd.

@ TeasingU :

Er is een speciale website opgericht door php experts dat gericht is op php en veiligheid/beveiliging
De link: http://www.phpsec.org/

Thnx voor de site. Dat ga ik ook doorlezen!

Nogmaals @ Crisp:

ok, challenge-response dus ....

Phoe ziet er lastig uit. Ik denk dus inderdaad dat ik de tips / stappen er wel uit ga gebruiken. Er zit iig nog wel heel wat prog werk in maar dat is juist leuk . Heeft iemand misschien nog een link naar een soort voorbeeld m.b.t. een challlenge response systeem Ik kom niet zo gauw uit op een nuttige site.

@ Sybr_E-N

In de P&W FAQ staat ook het een en ander over veiligheid en beveiliging van webapplicaties.

Een ander punt is dat je zomaar, zonder te controleren, gebruikersinformatie direct in je SQL-query opneemt. Ook dat neemt een risico met zich mee namelijk, SQL Injection en XSS (Cross Site Scripting). Oplossingen en best practices daarvoor in PHP kun met deze woorden wel vinden op Google.

Zoals ik al zei ga ik dat dus ook nog veranderen door Addslashes of jouw idee Dat moet ik dus nog even uitzoeken. Ook de FAQ heb ik zelfs in mijn 1e post staan, dus dat zit wel snor

Bedankt voor de reacties, en hoop er nog meer te krijgen om een mooi en goed login script te maken Ik hou jullie iig op de hoogte!!!

offtopic:
Mmm om 5:15 opstaan is geen pretje

[ Voor 3% gewijzigd door IJnte op 18-05-2005 20:34 ]

[Verwijderd]

Kijk, aan dit soort topics heb ik wat! Bedank voor je howto crisp!

[Suepahfly]

Ik heb ooit een een challence responce systeempje gebouwd om het pricipe er achter wat beter te begrijpen. Hier kan je die vinden. Tis zeker geen compleet login script, maar wel een aardige snippet die je aardig op weg kan helpen.

Let wel dat https altijd nog veiliger is.

[CH4OS]

Suepahfly schreef op donderdag 19 mei 2005 @ 16:12:
Let wel dat https altijd nog veiliger is.

IMHO is HTTPS pas écht veilig, met een geldig certificaat (al dan niet een SSL certificaat).

[IJnte]

Suepahfly schreef op donderdag 19 mei 2005 @ 16:12:
Ik heb ooit een een challence responce systeempje gebouwd om het pricipe er achter wat beter te begrijpen. Hier kan je die vinden. Tis zeker geen compleet login script, maar wel een aardige snippet die je aardig op weg kan helpen.

Let wel dat https altijd nog veiliger is.

Bedankt Ik ga het bestuderen !

Over SSL en HTTPS enzo ga ik ook nog wat lezen, maar misschien is dit wel echt overdone Maar goed, extra info is nooit weg natuurlijk, dus ik ga wat voorbeeldjes proggen en daar mee proberen alle termen die in dit topic staan te begrijpen voor mezelf.

Moet je trouwens voor die SSL certificaten nog iets speciaals doen

[CH4OS]

IJnte schreef op donderdag 19 mei 2005 @ 21:58:
Moet je trouwens voor die SSL certificaten nog iets speciaals doen

Jep... Vaak moet je dokken... En niet zo'n klein beetje ook... http://www.verisign.com is er een van, die ze verkoopt, en is ook (afaik) 'de grootste'...

[justmental]

HTTPS is meestal overdone, tenzij je een site voor een bank oid. aan het bouwen bent.
Je kunt je aandacht beter richten op risico's waarbij er geen netwerkverkeer onderschept hoeft te worden.
Heb je bijvoorbeeld een site waarbij gebruikers zelf content kunnen toevoegen (zoals een forum) dan kan een onzorgvuldige controle van die content op bijvoorbeeld javascript leiden tot sessie kapingen.

[Erkens]

alsof je door https te gebruiken meteen een veilig script hebt
het enige wat daarmee gebeurd is dat dat de verbinding encrypted is, meer niet.
die certificaten geven enkel aan dat je weet wie de andere kant is en dat je die kan vertrouwen

[IJnte]

Erkens schreef op vrijdag 20 mei 2005 @ 10:47:
alsof je door https te gebruiken meteen een veilig script hebt
het enige wat daarmee gebeurd is dat dat de verbinding encrypted is, meer niet.
die certificaten geven enkel aan dat je weet wie de andere kant is en dat je die kan vertrouwen

Owkee.. Ik heb er inderdaad inmiddels wat over gelezen. Beetje overdone idd. Het is voor een site waar mensen wat persoonlijke gegevens kunnen zien en een FTP verbinding tot stand kunnen brengen. Ook wordt de mogelijkheid ingebouwt voor een klein forum.

[meon]

Het toeval wilt dat ik net ook een community-gebaseerde website aan het opzetten ben en dus een login-functie nodig heb.
De loginfunctie op zich is op basis van bovenstaande tips wel veilig te krijgen, maar ik zou ook een "autologin"-functie moeten hebben. Per definitie moet zoiets via cookies, maar welke gegevens moet je daar dan in opslaan? Logisch is dat gebruikersnaam en wachtwoord, maar dat is niet veilig dus. Doelpubliek == België waar 99% van de IP's dynamisch zijn, dus koppelen aan IP is geen optie. Wat is dan wél de juiste werkwijze?

[Erkens]

sessie id, meer niet

een user logt een keer in, waarna je hem een uniek id geeft (welke je al dan niet naar keuze van de gebruiker kan locken op ip) welke bijvoorbeeld 1 jaar geldig blijft, in je database hou je dan bij welke ID's horen bij welke user.

[meon]

Dan kan je toch nog steeds de cookie stelen, of ben ik mis?
Krijg je dan niet een heleboel vervuiling in je sessie-tabel?

[Erkens]

meon schreef op zaterdag 21 mei 2005 @ 17:47:
Dan kan je toch nog steeds de cookie stelen, of ben ik mis?
Krijg je dan niet een heleboel vervuiling in je sessie-tabel?

tja, als je niet kan locken op IP dan is dat natuurlijk altijd mogelijk
en wat bedoel je met vervuiling?

[meon]

Nee, ik zit mis. Ik probeerde me de flow een beetje voor te stellen, maar natuurlijk wis je die entry in de tabel als je op 'logout' klikt.
De theorie heb ik ondertussen al een beetje in m'n hoofd, nu nog het ten uitvoer brengen

[Erkens]

en je ruimt natuurlijk de entries op zodra ze verlopen zijn.
Maar zoveel data is zo'n tabel niet, alleen een sessionID, userID, IPadres en minstens 1 datum veld (verloopdatum) eventueel natuurlijk nog logindatum en useragent als je die ergens voor wilt gebruiken

[Verwijderd]

IJnte schreef op dinsdag 17 mei 2005 @ 23:14:

PHP:

<? 
if($_SESSION['first_name'] == "" AND $_SESSION['password'] == "" AND $_SESSION['ip_address'] =="")
{
 if($_COOKIE['first_name'] == "" AND $_COOKIE['password'] == "" AND $_COOKIE['Ip_address'] == "")
 {
   if($_POST['naam'] != "" AND $_POST['ww_crypt'] != "")

En als je voor het eerst op de website komt, dan krijg je allemaal foutmeldingen?
Je gebruikt nergens de isset-functie.
Voor de rest niet naar de overige code gekeken.

[ Voor 41% gewijzigd door Verwijderd op 22-05-2005 01:55 ]

[MueR]

Verwijderd schreef op zondag 22 mei 2005 @ 01:53:
[...]

En als je voor het eerst op de website komt, dan krijg je allemaal foutmeldingen?
Je gebruikt nergens de isset-functie.
Voor de rest niet naar de overige code gekeken.

Je krijgt alleen waarschuwingen. Het vergelijken van de waarde van een variabele kan ook op een niet bestaande variabele, deze heeft dan gewoon de waarde NULL of is leeg.

[Verwijderd]

Er staat op phpfreakz.nl ook een goed nederlands artikel of algemene beveiliging in PHP.
Waarschijnlijk is dit ook wel interesant om te lezen:
http://www.phpfreakz.nl/artikelen.php?aid=106