[PHP] structuur login systeempje

[Arathorn8]

Ik ben bezig met een login ding voor gebruikers van een website. Wil mensen in laten loggen dmv hun e-mail adres, want ervaring leert dat men gebruikersnamen vaak vergeet. Het gaat even om de grondslag, die moet goed zijn.

Belangrijk is:

code:

CREATE TABLE users(uid INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
                    email VARCHAR(50) UNIQUE NOT NULL DEFAULT '',
                    password CHAR(32) BINARY NOT NULL DEFAULT '',
                    logged_in_stamp CHAR(32) BINARY NOT NULL) DEFAULT '')

Extra velden die er nu niet toe doen zijn weggelaten. De uid is alleen belangrijk voor de sql... verder wordt 't niet gebruikt. Het veld password bevat uiteraard de hash van het wachtwoord (md5).

Waar het mij nu om gaat is het laatste veld: logged_in_stamp. Daarin wil ik een hash opslaan dat ongeveer als volgt geproduceerd zal worden:

code:

<?php
session_start();
$sessionid = session_id();
$user_ip = $_SERVER['REMOTE_ADDR'];
$user_browser = $_SERVER['HTTP_USER_AGENT'];
$server_ip = $_SERVER['SERVER_ADDR'];

logged_in_stamp = md5($sessionid . $user_ip . $user_browser . $server_ip);
?>

Deze code wordt aangeroepen als er bij de bezoeken een cookie aangetroffen wordt, waarin staat dat hij/zij ingelogd zou moeten zijn. Timeout is niet zo zeer nodig, lijkt me.

Heeft iemand hier constructieve kritiek op? De browser id en het IP adres van de bezoeker lijken me persoonlijk genoeg om iedereen van elkaar te onderscheiden.

[WouZz]

Paar puntjes:

• sessionId zou op zich al uniek moeten zijn voor iedere gebruiker
• user agent kan ook leeg zijn
• user agent verandert na een browser update, wat zijn hiervan de gevolgen?

Oftwel, wat is het doel van je hash?

[Cartman!]

Zoek eens naar mensen die hier eerder om hebben gevraagd in de search. Dat je emailadres ipv. een naam gebruikt maakt voor het idee zelf natuurlijk niets uit. Genoeg over te vinden.

edit: verder nooit vertrouwen op gegevens van de user (ip, useragent etc.)

[ Voor 17% gewijzigd door Cartman! op 08-02-2008 14:42 ]

[muksie]

Z'n doel is waarschijnlijk om het kapen van de sessie wat moeilijker te maken.

Hou er rekening mee dat het bij scholen / bedrijven etc. voor kan komen dat meerdere PC's hetzelfde IP-adres hebben en vaak ook dezelfde browser. Echter zal in dit geval de sessionId natuurlijk nog wel uniek zijn.

[Arathorn8]

Cartman! schreef op vrijdag 08 februari 2008 @ 14:40:
Zoek eens naar mensen die hier eerder om hebben gevraagd in de search. Dat je emailadres ipv. een naam gebruikt maakt voor het idee zelf natuurlijk niets uit. Genoeg over te vinden.

Heb ik gedaan, maar kwam voornamelijk antieke draadjes tegen.

edit: verder nooit vertrouwen op gegevens van de user (ip, useragent etc.)

Ik kan die user agent wel achterwege laten. Die extra info maakt de hash echter iets minder voorspelbaar voor die kansloze hacker die de sessie wil kapen (idem voor de server_ip).

muksie schreef op vrijdag 08 februari 2008 @ 14:43:
Z'n doel is waarschijnlijk om het kapen van de sessie wat moeilijker te maken.

Hou er rekening mee dat het bij scholen / bedrijven etc. voor kan komen dat meerdere PC's hetzelfde IP-adres hebben en vaak ook dezelfde browser. Echter zal in dit geval de sessionId natuurlijk nog wel uniek zijn.

De site draait op een gedeelde server, dus daar gaat het idd om. Die meerdere pc's met hetzelfde ip, dezelfde browser dacht ik ook al aan. Dat probleem wil ik te lijf gaan door die session id in beschouwing te nemen. Die zou uniek moeten zijn voor elke user/computer/browser permutatie

[mithras]

Arathorn8 schreef op vrijdag 08 februari 2008 @ 15:02:
[...]

Heb ik gedaan, maar kwam voornamelijk antieke draadjes tegen.

Een methode, aanpak of algoritme zal niet heel snel verouderen. De beste manier om het te implementeren wel, maar alsnog kan je goed gebruik maken van oudere topics. Zie bijvoorbeeld [PHP] safelogin waarin ik ook refereer aan crisp in "[PHP] BeveiligingsTips nodig"

[mocean]

Ik zou die logged_in_stamp verplaatsen naar een losse tabel, waarin je je sessies opslaat. Dan kan je ook gemakkelijk fouten/raar gedrag tracken. Dan kan je ook meerdere sessies toestaan bijvoorbeeld (als je dat wilt), en elke sessie zijn eigen timeout geven.

[Verwijderd]

Het client-ip meenemen in de hash heeft als nadeel dat mensen die achter een cluster van proxies (=meerdere ip's) zitten op willekeurige momenten een login scherm voor hun neus krijgen. Een situatie die misschien niet vaak voorkomt, maar misschien toch iets om rekening mee te houden.