veilige login
Ik ben bezig een login script te maken.
Nu lees ik vaak wat over session hijacking e.d.
Hoe kun je een loginsysteem veilig maken? (korte uitleg vind ik voldoende)
Wat voor sessie moet dan precies opgeslagen worden in de database? (ik bedoel dus wat moet er in die essie staan?, een random code?)
ik heb al een sessie met de memberid van de gebruiker, wat voor sessies moet ik nog meer gebruiken?
is een met het IP ook nodig?
Gewijzigd op 11/01/2011 19:16:41 door Crude Oil
Ik sla bij een goede inlog op:
- Een cookie op met een hash (md5(), en uniqueid() op
- Een cookie met ID
En ik maak vervolgens in de database een record in de seeie tabel aan met diezelfde data.
Vervolgens heb ik een check_login() functie gemaakt die kijkt of de cookie overeenkomt met de inhoud uit de database. Zo ja: ingelogd (true)....
Als extraatje heb ik een optie die ik standaard aangevinkt houd met: IP-lock.
Hierbij wordt deze sessie aan het IP zelf gelocked, zodat deze niet werkt op een ander IP (als iemand cookies zou jatten).
Allemaal te vinden op http://multisess.clayweb.nl, alleen is de code wat verouderd :P
Gewijzigd op 11/01/2011 19:28:58 door - Ariën -
Als een van deze gegevens niet met elkaar overeenkomen, wordt de sessie gestopt.
Olie koning op 11/01/2011 19:29:52:
dank voor deze uitleg. Je gebruikt cookies in plaats van sessions?
Correct. De gebruiker heeft daar dan controle over, en zou dan zijn sessie die hij op school had gemaakt nog thuis kunnen afsluiten.
controleer of sessie overeenkomt met Sessie in Database + extra controle of sessie
in de User Table en die in Session table de zelfde waarde hebben.
anders Uitloggen en een melden geven dat de Sessie is verlopen.
Gewijzigd op 11/01/2011 20:51:43 door Dindong Veter
- Aar - op 11/01/2011 19:55:57:
Correct. De gebruiker heeft daar dan controle over, en zou dan zijn sessie die hij op school had gemaakt nog thuis kunnen afsluiten.
Olie koning op 11/01/2011 19:29:52:
dank voor deze uitleg. Je gebruikt cookies in plaats van sessions?
Correct. De gebruiker heeft daar dan controle over, en zou dan zijn sessie die hij op school had gemaakt nog thuis kunnen afsluiten.
kan dat?
dat wist ik nog niet
Olie koning op 11/01/2011 20:56:02:
kan dat?
dat wist ik nog niet
dat wist ik nog niet
Ligt eraan, ik zelf controleer ook nog de IP Adress
Zit geloof ik nog niet in de versie zelf die ik ter download aanbiedt.
inloggen =>
Dump session tabel: session key (random), session_id (user id md5 en unique id) ip adress
Dump User Tabel: update Session en Ipadress
als session key en session niet overeenkomen uitloggen, als ip niet overeen komt ook, als user id niet overeenkomt ook
enzevoort.
Gewijzigd op 11/01/2011 21:45:44 door Dindong Veter
Paul L op 11/01/2011 21:43:50:
Ik vind mijn Beveiliging wel wat overdreven, maar ja liever te veilig als te onveilig.
inloggen =>
Dump session tabel: session key (random), session_id (user id md5 en unique id) ip adress
Dump User Tabel: update Session en Ipadress
als session key en session niet overeenkomen uitloggen, als ip niet overeen komt ook, als user id niet overeenkomt ook
enzevoort.
inloggen =>
Dump session tabel: session key (random), session_id (user id md5 en unique id) ip adress
Dump User Tabel: update Session en Ipadress
als session key en session niet overeenkomen uitloggen, als ip niet overeen komt ook, als user id niet overeenkomt ook
enzevoort.
en waarom dan zowel een session_key als een session_id?
Toevoeging op 12/01/2011 20:51:30:
Hoe moet je de sessies overigens verwijderen? met session_destroy? of met session_unset?
session_key = Random String bij het inloggen
met session_destroy(); verwijder je alle sessie
met session_unset kun je een door jouw aangewezen sessie verwijderen
d.m.v unset($_SESSION['tim']);
vind je het wel veilig om gebruikersgegevens in je sessie op te slaan?
Een MD5 string kan ook met brute force gehacked worden...
Een IP-adres kan door meerdere bezoekers gebruikt worden.
En het User-ID dat erin staat kan ook 'nuttig' gebruikt worden.
Het lijkt dan wel veilig, maar met bruteforce kan er nog veel informatie vrijkomen.
Persoonlijk gebruik ik een volledig random token in de sessie waarmee de gebruiker wordt gevalideerd op de database. Alleen nutteloze informatie in de sessie, en alles wat bruikbaar is in de database opslaan.
Quote:
Een MD5 string kan ook met brute force gehacked worden...
Totdat je een 'salt' gebruikt...
Paul L op 12/01/2011 22:04:05:
session_id = User id
session_key = Random String bij het inloggen
session_key = Random String bij het inloggen
duidelijk, ik had session_id verkeerd begrepen :)
- Aar - op 13/01/2011 00:51:54:
Totdat je een 'salt' gebruikt...
Quote:
Een MD5 string kan ook met brute force gehacked worden...
Totdat je een 'salt' gebruikt...
Is ook geen probleem. Gewoon met een goede GPU brute forcen en de goede programma vinden.
Is maar net wat een hacker ervoor over heeft.
Gewijzigd op 13/01/2011 09:15:07 door - Dave -
- Dave - op 13/01/2011 09:14:51:
Is ook geen probleem. Gewoon met een goede GPU brute forcen en de goede programma vinden.
Is maar net wat een hacker ervoor over heeft.
- Aar - op 13/01/2011 00:51:54:
Totdat je een 'salt' gebruikt...
Quote:
Een MD5 string kan ook met brute force gehacked worden...
Totdat je een 'salt' gebruikt...
Is ook geen probleem. Gewoon met een goede GPU brute forcen en de goede programma vinden.
Is maar net wat een hacker ervoor over heeft.
Was dat niet zo dat dat maanden tot jaren kon duren?
Hoe langer de 'salt' en je passwoord, hoe lastiger het wordt om te brute-forcen.
Gewijzigd op 13/01/2011 09:38:04 door - Ariën -
- Dave - op 13/01/2011 09:14:51:
Is ook geen probleem. Gewoon met een goede GPU brute forcen en de goede programma vinden.
Is maar net wat een hacker ervoor over heeft.
Is maar net wat een hacker ervoor over heeft.
Ben ik dat of is een GPU een Graphics Processing Unit? Iets wat dus helemaal niets hoeft te kraken.. Ik denk dat je een CPU bedoelt.
