Veiligste manier login script
Ik zie echt gigantisch veel manieren voorbij komen om jou login zo veilig mogelijk te maken. Echter heeft elke manier wel een nadeel tot nu toe.
Aangezien het tegenwoordig niet te missen is dat gebruikers de website bezoeken via een mobieltje is het niet meer mogelijk om in combinatie met een ip een hash te maken. Er was een paar dagen terug een discussie gaanden over session hijacking waar eigenlijk veel verschillende oplossingen uit voortkwamen.
In hoeverre kan een sessie gekaapt worden?
Bijvoorbeeld. Je logt in. Er word een sessie aangemaakt met ID:1234567890. In deze sessie bevinden zich: userid = 1 en hash = jbhfgndjhsvghdnkf. Is het nu mogelijk om de complete sessie te kapen?
Cookies
En als je de hash nou opslaat in een cookie. Is het dan niet mogelijk deze ook te kapen?
Het kapen testen
En hoe kaap je een sessie? Als we dat allemaal zouden weten konden we testen of onze beveiliging goed genoeg is.
Ik zou toch graag nu samen met de kennis van iedereen die mee wilt denken komen tot een goede opzet van een beveiliging. Het hoeft niet perce in codes, maar kan ook in stappen: Wat sla je op, wat controleer je, hoe sla je het op, etc...
Mik
Gewijzigd op 09/10/2012 16:47:48 door Mik PHP
dus zoiets:
Code (php)
1
ip.welkbrowser.browserversie.os
maak daar een hash van en controleer elke keer of die nog steeds hetzelfde is. Dat is wat ik meestal doe. Het kapen van een sessie kan dan nog steeds maar de kans is velen malen groter dat de sessie dan als ongeldig word bestempelt.
zie: http://nl3.php.net/get_browser
Gewijzigd op 09/10/2012 17:49:56 door Mebus Hackintosh
Stel we hebben gebruiker Piet en hij gaat naar website X en hij logt in. Op de computer van Piet wordt nu een cookie met daarin een sessie-id opgeslagen. Iedere keer dat Piet nu een pagina bezoekt op website X (zolang hij de browser niet afsluit) leest website X de cookie uit met daarin het sessie-id. Laten we doen alsof het sessie-id 1234 is (in werkelijkheid is dit een veel langere en minder voor de hand liggende string).
Iedere keer als Piet nu dus een pagina op website X bezoekt, leest website X de cookie uit en zo "weet" website X dat het Piet is.
Wat nu als een hacker, bijvoorbeeld Bas K. :-), zo'n cookie faket. Hij zet op zijn computer precies dezelfde cookie met precies dezelfde inhoud als de cookie die op de computer van Piet staat. Aiiii... nu krijgt Bas K. dus dezelfde gegevens te zien als Piet. Als Bas K. nu bijvoorbeeld naar "accountgegevens wijzigen" gaat, kan het zomaar zijn dat hij het e-mailadres van Piet te zien krijgt en kan hij misschien wel zijn wachtwoord wijzigen.
Oké, hoe weet Bas K. nu wat er in de cookie van Piet staat? Niet! Maar een goede hacker kan gewoon heel veel combinaties uitproberen, totdat hij een keer "beet" heeft.
Hoe kunnen we dit voorkomen? Door een extra cookie op de computer van Piet te plaatsen. Zodra Piet inlogt, wordt er door website X nog een extra cookie op zijn computer opgeslagen met daarin een code, bijvoorbeeld (even versimpeld) 54321. Deze code wordt door website X samen met het sessie-id opgeslagen in de database. Telkens als Piet nu een pagina bezoekt, wordt gecontroleerd of het sessie-id uit de cookie en de code uit de andere cookie gelijk zijn aan de gegevens in de database.
Daar hebben we hacker Bas K. weer. Boem, een toevalstreffer!! Bas K. vindt de sessie-id van Piet! Maar wat een geluk, hij weet de code uit de extra cookie niet. Website X ziet dat de sessie-id klopt, maar... de extra code klopt niet! De complete sessie wordt nu direct vernietigd.
Volgens mij is dit een aardig veilig script en werkt volledig met Session ID regenerate op het moment dat een pagina geladen wordt. Dus elke keer veranderd het sessie ID
Stefan van den Broek op 11/10/2012 10:43:40:
Ik heb even vlug naar de tutorial gekeken (echt maar 2 minuten), het eerste wat mij opvalt is het creëren van de hash in JavaScript. Dit vind ik geen succes, iemand die een beetje IT ervaring heeft kan zo JavaScript uitzetten in zijn browser. Dit zou ik persoonlijk dus in PHP doen.
Uitzetten van javascript kan, echter kan je dan niet meer inloggen... dus dat zou niet uitmaken. Het stukje javascript voor de hash zorgt ervoor dat het wachtwoord niet wordt verzonden via een Post zonder hem eerst te encrypten
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
// HTTP-only sessiecookie gebruiken
ini_set('session.cookie_httponly', '1');
// MD5 (128 bits) vervangen door SHA-1 (160 bits) voor een sterkere hash
ini_set('session.hash_function', '1');
// Sessieduur verkorten van 180 minuten (3 uur!) tot 5 minuten (300 seconden)
ini_set('session.gc_maxlifetime', 300);
session_cache_expire(5);
// Sessies niet opslaan op caching proxy servers
session_cache_limiter('private_no_expire');
// Hierna pas de sessie starten of hervatten
session_start();
// Bij elk verzoek een nieuwe sessie-ID genereren
session_regenerate_id(TRUE);
?>
// HTTP-only sessiecookie gebruiken
ini_set('session.cookie_httponly', '1');
// MD5 (128 bits) vervangen door SHA-1 (160 bits) voor een sterkere hash
ini_set('session.hash_function', '1');
// Sessieduur verkorten van 180 minuten (3 uur!) tot 5 minuten (300 seconden)
ini_set('session.gc_maxlifetime', 300);
session_cache_expire(5);
// Sessies niet opslaan op caching proxy servers
session_cache_limiter('private_no_expire');
// Hierna pas de sessie starten of hervatten
session_start();
// Bij elk verzoek een nieuwe sessie-ID genereren
session_regenerate_id(TRUE);
?>
session_cache_expire(5);
en
session_cache_limiter('private_no_expire');
Als je een site verlaat of het browservenster sluit, blijft het sessiecookie standaard 180 minuten beschikbaar. Deze levensduur (TTL) gaat steeds opnieuw in bij elk volgend HTTP-verzoek. De standaardinstelling van PHP is echter 3 uur (!) en dat is voor veel soorten websites veel te lang. Als de meeste bezoekers na bijvoorbeeld 5 minuten niets meer te hebben gedaan toch niet terugkeren, heb je een sessie die feitelijk niet meer wordt gebruikt, maar nog wel enkele uren kan worden misbruikt. Verkorten dus.
De cachelimiter regelt de HTTP-headers die voor caching worden verzonden. Hier wil je bijvoorbeeld vooral niet een 'Cache-Control: public' hebben, want dan kan het sessiecookie in theorie worden opgeslagen op een gedeelde proxy.
Je kunt eens kijken naar de HTTP-headers van die site. Maar uiteindelijk is de client de baas over de clientcache. Als een browser een streng beveiligingsbeleid heeft met een beslissingsregel zoals "wis alle cookies bij het sluiten van een venster", dan kan een server daaraan niets veranderen.
Ward van der Put op 11/10/2012 11:39:46:
Bij veel sites is het omgekeerde het geval: als je per ongeluk een browservenster sluit of doorklikt naar een andere site maar binnen enkele minuten terugkeert, is je sessie niet reddeloos verloren. Op zich handig, want dan blijft de browserknop Back/Vorige bruikbaar en verlies je niet automatisch enkele minuten werk.
Ward, dit is logisch, want je hebt de browser niet afgesloten, dus kun je gewoon weer terug naar die site. Echter jij zei dat de sessie cookie actief blijft na het sluiten van de browser. Daar ging mijn vraag over.
Weet hacker Bas K. nu mijn sessie/cookie na te bootsen, mag hij ook tot in detail OS/Browser etc nabootsen.
Succes Bas K!
Gewijzigd op 11/10/2012 15:21:33 door Sander Z
http://www.phphulp.nl/php/forum/topic/user-fingerprinting/71377/