Veiligste manier login script

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Mik PHP

Mik PHP

09/10/2012 16:41:32
Quote Anchor link
Hey allemaal,

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
 
PHP hulp

PHP hulp

24/01/2020 18:19:17
 
Mebus  Hackintosh

Mebus Hackintosh

09/10/2012 17:49:20
Quote Anchor link
Altijd nog het ip adres van de gebruiker gehasht in een sessie opslaan en daar misschien de browser aan vast geplakt die die gebruikt.

dus zoiets:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
 
Mik PHP

Mik PHP

09/10/2012 17:57:54
Quote Anchor link
IP hashen is niet slim aangezien het ip-adres van een mobiel constant verandert.
 
Ozzie PHP

Ozzie PHP

11/10/2012 08:49:34
Quote Anchor link
Ik denk dat je het als volgt moet zien:

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.
 
Marvin H

Marvin H

11/10/2012 10:04:32
Quote Anchor link
Ik had o.a. de volgende tutorial gevonden: http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL

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 WM

Stefan WM

11/10/2012 10:43:40
Quote Anchor link
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.
 
Marvin H

Marvin H

11/10/2012 10:47:34
Quote Anchor link
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
 
Ozzie PHP

Ozzie PHP

11/10/2012 10:49:36
Quote Anchor link
Stefan, volgens mij is dat alleen een extra veiligheid om de inloggegevens niet in plain text over het web te hoeven sturen. Vraag me alleen wel af wat er gebeurt als javascript uitstaat. Dan wordt het alsnog onversleuteld verzonden. Echter, de server verwacht een versleutelde versie...
 
Ward van der Put
Moderator

Ward van der Put

11/10/2012 10:52:02
Quote Anchor link
Wat je op zijn minst kunt doen (of misschien wel: moet doen), is standaardmogelijkheden van PHP benutten, bijvoorbeeld:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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);
?>
 
Ozzie PHP

Ozzie PHP

11/10/2012 11:05:16
Quote Anchor link
Ward, kun jij eens toelichten wat dit doet. Met name:

session_cache_expire(5);

en

session_cache_limiter('private_no_expire');
 
Ward van der Put
Moderator

Ward van der Put

11/10/2012 11:17:16
Quote Anchor link
Beide regelen het cachemechanisme van het sessiecookie op clients.

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.
 
Ozzie PHP

Ozzie PHP

11/10/2012 11:29:53
Quote Anchor link
Hmm, oke... ik kan me niet herinneren dat ik ooit die session_cache_expire heb ingesteld (maar ik kan er naast zitten). Toch is het zo dat als ik ben ingelogd op een website en ik de browser sluit... en de browser weer open... dat ik dan niet ben ingelogd. Hoe kan dat dan?
 
Marvin H

Marvin H

11/10/2012 11:32:52
Quote Anchor link
Het heeft ook geen nut om de cache limit te activeren vanwege session_regenerate_id(TRUE); ... hij veranderd toch bij elke klik / $_POST of aanroepen van een PHP. Tevens verloopt de Session Cookie automatisch bij het beëindigen van de sessie zelf, vanwege Cookie lifetime = Session Lifetime
 
Ward van der Put
Moderator

Ward van der Put

11/10/2012 11:39:46
Quote Anchor link
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.

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.
 
Ozzie PHP

Ozzie PHP

11/10/2012 11:52:49
Quote Anchor link
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.
 
Ward van der Put
Moderator

Ward van der Put

11/10/2012 12:11:36
Quote Anchor link
Ozzie, dat is waar: moderne browsers hanteren inderdaad het beginsel dat het einde van een browsersessie meteen een einde maakt aan alle lopende sessies. Alleen, op wat de meeste clients doen bij de standaardinstellingen, kun je nooit vertrouwen.
 
Ozzie PHP

Ozzie PHP

11/10/2012 12:20:20
Quote Anchor link
Oké... ik zal er voortaan rekening mee houden... thanks.
 
Sander Z

Sander Z

11/10/2012 15:21:13
Quote Anchor link
Bij een corercte login maak je een session ID aan welke in de cookie en je DB komt. Maar je slaat ook direct gegevens van de gebruiker/pc op: Browser/OS etc. (fingerprint)
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
 
Ozzie PHP

Ozzie PHP

11/10/2012 15:23:00
Quote Anchor link
hoe maak jij zo'n fingerprint?
 
Ward van der Put
Moderator

Ward van der Put

11/10/2012 15:37:24
Quote Anchor link
Een belangrijk bestanddeel van een fingerprint is $_SERVER['HTTP_USER_AGENT'] met info over de client:

http://www.phphulp.nl/php/forum/topic/user-fingerprinting/71377/
 
Ozzie PHP

Ozzie PHP

11/10/2012 15:44:25
Quote Anchor link
Dankjewel Ward... dat is dus gewoon een kwestie van zelf een aantal variabelen "aan elkaar plakken" en hashen?
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.