Simpel, veilig login systeempje

Waarom .inc.php?

Waarom heet jij Tommy ?

Ik zie dat je cookies gebruikt voor het opslaan van de " user_id ", Is het niet beter om dat met $_SESSION te doen?

Vooral omdat ze in de EU zich aan het bemoeien zijn met het gebruik van cookies. Al hoop ik niet dat dit ook voor $_SESSION geld.

@Tommy:
Omdat ik dat handig vind. Ik weet dan dat die pagina's alleen ge-include worden.

@Mario Lamers:
Zou je onzin berichtjes achterwegen willen laten, niet dat de vraag van Tommy nou zo intelligent was, maar jou bericht slaat nergens op.

@Mark:
Hmm... Een session is weg als je je browser afsluit, dus dan ben je weer uitgelogd. Dat is in sommige gevallen niet handig.
Zolang de EU nog niets concreets heeft afgesproken zijn cookies volgens mij het handigste.

Een cookie bij mij ook hoor. Ik heb FF zo ingesteld dat alles wordt gewist bij het afsluiten van de browser. Het is ook iets persoonlijks, Ik will niet dat er inlog gevens op een computer staan, Vooral niet als ik ergens anders ben ingelogd. Het is nu alleen het ID maar dan nog.

@Tommy, doe ik ook hoor. In vele opzichten handig

Fatal error: Class 'mysqli' not found in /usr/export/www/hosting/gamet/deal/inc/config.inc.php on line 16

@zardac2:
Ondersteund jou host wel MySQLi? (check je phpinfo(); )

De hash is nu wel voorspelbaar. In theorie zou ik als iemand anders kunnen inloggen door de cookies aan te passen.

Stel dat ik van achter hetzelfde ip-adres internet (zelfde universiteitsnetwerk, zelfde bedrijf, niet heel moeilijk) als mijn slachtoffer, ik z'n gebruikerId weet (meestal wordt dat al gebruikt om naar z'n profiel te linken) en ik weet wat voor browser hij gebruikt (meest recente versie van Firefox, de IE die op alle schoolcomputers is geïnstalleerd) dan zou ik zelf de user_hash cookie kunnen genereren, en user_id cookie netjes invullen. Zolang hij niet op "uitloggen" heeft gedrukt (wat ik niet verwacht, want dat doet niemand behalve op een bank-site) zou ik geen probleem moeten hebben met het inloggen onder zijn account.

Als je nog iets onraadbaars (bijv. uniqid) toevoegt aan die hash, en ook opslaat in de database zodat je zelf de controle-hash kan genereren, is dat probleem opgelost :)

Op jou site krijg je waarschijnlijk de sessie-id aan de url vast geplakt. Dit wordt afgeraden i.v.m. SEO en omdat je problemen kunt krijgen (sessies stelen bijvoorbeeld).
PHP is standaard ingesteld dat die cookies moet gebruiken voor sessies én ook alleen maar cookies mag gebruiken voor sessies, zie session.configuration#ini.session.use-cookies en session.configuration#ini.session.use-only-cookies.
Dus jou argument dat Arwin geen cookies zou moeten gebruiken klopt niet, aangezien je met sessies nog steeds een cookie gebruikt.
(En dat de Europese Unie cookies gaat verbieden zal er of niet door komen, of nog héél lang duren (als er een andere manier is).)

Ik heb niet alles bekeken maar zo op het eerste gezicht ziet het er erg goed uit. Zelfs de sqlletjes zijn netjes uitgeschreven

@Jelmer:
Bedankt voor je duidelijke uitleg! Ik heb meteen de extra hash, unigid ( uniqid(mt_rand(), true) ), aan het systeem toegevoegd.

@Karl: Dank voor de opheldering.

@Klaasjan Boven: Dank je.

Is er ook een voorbeeldje online?

Even een weetje:

@Mario Lamers
Tommy vraagt waarom iemand .inc.php zou doen?

Aan de ene kant heb jij gelijk, aan de andere kant kan het best een reden hebben. Weinig mensen weten dit maar inc. is een afkorting.

Inc. - Incorperated of Include
In het Nederlands is het Incl.
Inclusief.

Dus waarom zouden mensen hun bestanden .inc.php noemen denk je Tommy?
Hou het maar bij dat mensen niet alleen netjes scripten,
maar ook van alles opgeruimd en gecat. in mapjes.

Over het script, ik heb serieuze vraagtekens bij het datamodel. Raar dat ik niemand daar nog over gehoord heb.
- ipadres` varchar(255) NOT NULL, vervolgens `ip` varchar(50) NOT NULL en dan nog eens `ip` varchar(16) NOT NULL. Houdt één enkel type aan, voor een ip voldoet in MySQL een unsigned integer.
- je gebruikt sha1, dit geeft altijd 40 karakters. Varchar(255) is dus te groot. Dit geldt ook voor de beide hashvelden.
- Same story m.i. voor de naamvelden, een tussenvoegsel van 255 tekens? Overbodige ruimte.
- Als laatste mis je ook nog eens foreign keys, wat dat betreft valt er aan dit model nog genoeg te verbeteren.

PS ik zie dat je enkele varchar velden van boven de 255 karakters definieert. Dit is pas mogelijk vanaf MySQL 5.0.3, dus ik geef je hierbij het voordeel van de twijfel.

@JOni
Indien je alle bestanden netjes gecategoriseerd hebt in mappen, zou je juist .inc.php niet nodig hebben. Hetzelfde geldt voor iets als .class.php, ook zo'n gek verzinsel.

Plaats alles in duidelijke mappen, of houd een consistente naamgeving aan. Ik kan aan een bestandsnaam meteen zien wat zich er in het bestand bevindt, een (abstracte) klasse, interface of iets anders.

@Agirre:
Het database model heb ik aangepast. Ben benieuwd wat je er van vind.

ik ben een absolute newbie en zou het wel als voorbeeld willen zien. waar moet ik daarvoor zijn?

@nimtex en @lucien:

Er is geen voorbeeld online maar kan jullie het wel even uitleggen:
Bij index.php zie je een 2 veldjes voor je gebruikersnaam en wachtwoord, en een button 'Inloggen'.

Als je inlogt komt er te staan: 'Je bent ingelogd!'.
Als je dan naar logout.php gaat, komt er te staan, 'Je bent uitgelogd'

Dat is eigenlijk alles. Heel simpel, zonder mooie opmaak.

@Aqirre:

Ook al geef ik je gelijk, er is geen verschil in geheugengebruik tussen VARCHAR(40) en VARCHAR(255). Beiden gebruiken 1+str.length bytes. Pas boven de 255 krijg je 2+str.length bytes.

Wat doet hij met ipv6? ;)

Demo online
http://phphulp.digi-nl.com/login/

Alleen ik krijg geen persoon in DB toegevoegd... xD
SH1? of MD5 of iets anders?

Lijkt sha1

index.php regel 39

@Mr. Bean en Nimtex:
Ik heb de functies.inc.php pagina net aangepast omdat daar nog een fout in stond. Hopelijk doet hij het nu wel goed.

Helaas werkt het nog steeds niet, Ik heb me password SHA1 gehashed maar hij weergeeft nog steeds dat ik de verkeerde login gegevens heb. Wie kan mij opweg helpen. want ik volg het niet echt meer :S

@nintex,

Je moet je password én gebruikersnaam hashen:

sh1($$usrname.$__POST['pass'])

Als je wachtwoord dus "123456" is en je gebukersnaam "halllo", dan moet je de output van:

in de database zetten.

Oke maar waarom dan gebruikersnaam en wachtwoord veld in de database? dan heb je nu toch alleen een wachtwoord uiteindelijk??

Voorbeeld:
http://phphulp.digi-nl.com/login/

Gebruikersnaam: test
Wachtwoord: test

Voorbeeld:
http://phphulp.digi-nl.com/login/

Gebruikersnaam: test
Wachtwoord: test

@nimtex: Ik wil met een gebruikers ID wel een gebruikersnaam uit de database kunnen halen, als het sha1 gehashed is kan dat niet. De gebruikersnaam is zeg maar de SALT-KEY.

Dus als ik het goed begrijp heb ik het volgende:

gebruikersnaam = gebruiker
wachtwoord = phper

moet er in de mysql tabel komen:

gebruikersnaam = gebruiker
wachtwoord = sha1(gebruikerphper) dus plak ik mn gebruikersnaam en wachtwoord achter elkaar en zet ik het om in SHA1. Klopt dat?

Ja, probeer maar, dan zal je zien (als je het goed doet) dat het werkt.

@Arwin, mijn vb kan je wel bij voorbeeld zetten :)
Blijft nog een lange tijd online staat :)

Ik heb nu inderdaad gedaan wat jullie zeiden alleen nu krijg ik dat de header als verstuurd zijn maar ik ben wel ingelogd!!! Wie kan me helpen? Ik heb alle html tags al van me pagina afgehaald

Warning: Cannot modify header information - headers already sent by (output started at /home/vhosts/(website)/subdomains/portal/httpdocs/login/functies.inc.php:60) in /home/vhosts/(website)/subdomains/portal/httpdocs/login/index.php on line 61

Warning: Cannot modify header information - headers already sent by (output started at /home/vhosts/(website)/subdomains/portal/httpdocs/login/functies.inc.php:60) in /home/vhosts/(website)/subdomains/portal/httpdocs/login/index.php on line 62
Je bent ingelogd!

Bumpje voor het bovenstaande bericht *mag toch wel?*

Kan je beter even een nieuw topic maken..

@ nimtex

Even snel alles doorgelezen.
Je moet volgens mij functies nog includen in je login.php.

Oke ga ik doen, mocht dit niet lukken volg ik de raad van Chris Kortaan op!

Mooi script + rep

Waar blijft het registratie formuliertje?

geen idee :P

@tom heek & jasper:
heb hem online gezet, succes ermee.

mijn vraag is : wat is nu aanraadbaar : sessies of coockies, ik hoor van diverse mensen dat je maar coockies hoeft te wijzigen en je bent in iemands anders account, en hier staat dat sessies weer onveillig zijn. Wat is nu het goede en veiligste redument ?

@Kevin van Leeuwen, Cookies zijn niet onveilig mits je ze goed gebruikt. Soms wordt een ID of wachtwoord opgeslagen in een Cookie en controleert de site hier alleen maar op. Zo'n Cookie kan je stelen en daarmee gewoon binnen komen.
Sla sowieso nooit geen wachtwoorden op in Cookies en controleer ze bijvoorbeeld op IP adres o.i.d.
Gebruik Cookies alleen als je de gebruiker ingelogd wil laten blijven. Sessies, zoals de naam al zegt, zijn voor één sessie. De gebruiker krijgt bij langer tijd inactief op sluiten van de browser een nieuwe sessie waardoor de gebruiker weer moet inloggen.
Ook sessies kunnen onveilig zijn als je hier het wachtwoord in opslaat en niet goed controleert.

1: In je registratie voorbeeld probeer je het ip adres op te slaan in de kolom 'ipadres', terwijl deze kolom in je table 'ip' heet.
2: Legitieme emailadressen worden geweigerd bij de registratie.
Maar goed, het is maar een voorbeeld bestand.

Wat in je daadwerkelijke systeem niet kopt is je aantal login pogingen. Als je in je config.inc.php een getal invult krijg je daadwerkelijk +2 pogingen.
Dus vul je daar 2 in dan krijgt een gebruiker 4 pogingen voordat hij daadwerkelijk gebant wordt.

Belangrijk detail vind ik wel dat er altijd en alleen maar gebruik wordt gemaakt van cookies. Er zijn maar weinig gebruikers die netjes na gebruik uitloggen. En met dit script blijf je dan altijd ingelogd, de persoon na mij kan dus onder mijn gegevens verder!
En als ik op een publieke PC zit wil ik een sessie hebben ipv een cookie...
Zonder uit te loggen maar wel de browser af te sluiten ben je alle gegevens al weer kwijt. Dat maakt het dan wel al weer een stukje veiliger.

En nog mooier zou zijn dat als je op een publieke PC zit en bv 5 minuten geen pagina's opent of bekijkt je sessie niet meer geldig is.

Verder ziet het er netjes uit.