Ik ben een systeem aan het maken voor een bedrijf waarbij ik zoveel mogelijk wil voorkomen dat hackers het systeem in kunnen komen. Ik weet dat dit onmogelijk is als iemand het echt op je gemunt heeft, maar alle beetjes helpen denk ik dan maar.
Ik ben van plan om op de volgende manieren te werk te gaan:
1. gebruiker logt in waarbij bcrypt hashes van het ingevoerde wachtwoord en de hash die in de db staat worden vergeleken.
2. als de hashes kloppen worden er session variabelen aangemaakt met gegevens van de gebruiker. Zie:
3. om te controleren of een gebruiker is ingelogd voordat de pagina wordt getoond gebruik ik:
[script]
<?php
if(!isset($_SESSION['gebruikers_id''])){
echo "<p>U heeft geen toegang</p>";
exit;
}
?>
[/script]
Naast deze 3 punten wil ik de user agent opslaan in een sessie variabele als de gebruiker inlogt. Op elke volgende pagina controleer ik of de user agent hetzelfde is gebleven anders vernietig ik de sessie.
Denken jullie dat ik zo goed op weg ben, of ben ik hier verkeerd bezig en/of hebben jullie nog tips?
Afgaan op $_SERVER['HTTP_USER_AGENT'] helpt je niet bij phishing en dergelijke. De hacker/cracker kan de gebruiker naar een fake site lokken (bijvoorbeeld in een onzichtbaar frame) of de gebruiker een mailtje laten lezen via webmail en heeft dan direct deze HTTP-header te pakken.
Verder heeft encryptie van de user agent in de database niet veel zin, want het is slechts een extern gegeven waarvan je alleen maar wilt weten of het gewijzigd is. Daarvoor voldoet een asymmetrische hash.
Je kunt hier zowel strengere als sneller code gebruiken, bijvoorbeeld inclusief een IP-adres:
<?php
function save_ua()
{
$hashed_ua = sha1($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
$stmt = $database->prepare('UPDATE gebruikers SET user_agent=:user_agent WHERE gebruikers_id = :gebruikers_id');
$stmt->execute(array('user_agent' => $hashed_ua, 'gebruikers_id' => $_SESSION['gebruikers_id']));
}
?>
Davey Mat op 25/04/2014 13:29:06
Daarnaast begrijp ik Micheal- dat sessie variabelen niet als veilig moeten worden beschouwd, dus zal ik enkel de gebruikers_id uit de database in een sessie variabele opslaan. De rest vraag ik iedere keer met een query op.
Nee, dat is zonde. De sessievariabelen zijn veilig opgeslagen in (meestal) een file cache in een server-directory buiten de root, waar helemaal niemand bij kan. Je verliest een van de voordelen van sessies als je dat vervangt door databaseverkeer. Je hebt dan bijvoorbeeld meer databaseverbindingen nodig en je hebt ze langer nodig.
Wat ik wel nog mis, is het loggen van fouten en het blokkeren van een account of een IP-adres. Je vernietigt nu de sessie, maar na de redirect kan iemand gewoon een nieuwe poging wagen. Miljoenen keren zelfs...
User agent kan tijdens een sessie ook veranderen...
Bovendien hoef je de sessie bij een gewijzigde user agent of een ander IP-adres natuurlijk niet te vernietigen. Wel kun je constateren dat er ondertussen iets bij de client structureel anders is. Dat kán een reden zijn om ergens extra controles in te bouwen.
Bijvoorbeeld: normaliter mag je je accountgegevens na inloggen wijzigen, maar nu staat er een vlaggetje op rood en moet je ter bevestiging nog even opnieuw je wachtwoord invullen.
Wat ik wel nog mis, is het loggen van fouten en het blokkeren van een account of een IP-adres. Je vernietigt nu de sessie, maar na de redirect kan iemand gewoon een nieuwe poging wagen. Miljoenen keren zelfs...
Precies en deze is echt heel belangrijk want dit is de manier op een password te raden.
dus na laten we zeggen een keer of 20 mislukte login direct het ip blokkeren.
Vervolgens denk ik altijd maar aan het afsluiten van je woonhuis:
De achterdeur draai je drie keer in het slot en als je thuis komt is je hele huis overhoop gehaald: blijkt het slaapkamerraam nog open te staan..
Dus:
- goede sterke wachtwoorden gebruiken voor de login maar ook voor de database en de ftp server.
- zo weinig mogelijk informatie prijsgeven bij foutieve inlogpogingen. enkel een melding 'Geen toegang' is wat mij betreft genoeg.
- Zoals al gezegd: gebruik een beveiligde internet-verbinding.
- Sla de wachtwoorden gecodeerd op in de database.
- Desgewenst log je de inlogpogingen. Indien er vele pogingen in korte tijd bijkomen kun je nog een email laten versturen naar de beheerder. Deze kan vervolgens beslissen of de site misschien tijdelijk offline moet.
- Overweeg het gebruik waar filters. Bijvoorbeeld: inloggen enkel vanuit nederland of enkel bepaalde ip-adressen
Bedankt allemaal voor de reacties! Hier kan ik zeker weer mee aan de slag.
Dit zal ik deze week ook allemaal gaan doen. Op het lijstje:
-user agent + ip adres controle waarna de gebruiker bij verandering nog wel content kan zien, maar niet kan aanpassen, verwijderen etc.
-loggen van fouten en ip adressen die aanmelden en/of brute force proberen waarna ik na bv 10-20x foutief inloggen binnen een uur het ip adres blokkeer(blokkeren is gewoon te vertrouwen als ik in php hiermee werk? Dus een database tabel met geblokkeerde ipadressen en dan elke keer als iemand een pagina opent kijken of dit van een geblokkeerd ip adres komt, dan een fout weergeven. Of is er een betere manier?)
-mail naar systeembeheer bij veel aanmeldingen op 1 gebruiker o.i.d. binnen een tijdsbestek van 1 uur.
-inloggen enkel via de ip reeksen van landen waar gebruikers vandaan komen (Nl/BE)
@Ozzie: Ik denk dat Ward bijvoorbeeld bedoelt dat als iemand de sessie van een gebruiker kan "stelen". De hacker kan daarna met deze sessie verbinding maken met de website, maar als hij/zij een andere user agent heeft dan merken we dat dus op en blokkeren we bepaalde functies. Daarnaast kan iedereen zijn user agent veranderen. Zie bijvoorbeeld: http://www.howtogeek.com/113439/how-to-change-your-browsers-user-agent-without-installing-any-extensions/
