Hallo,
Welke informatie is het beste/veiligste om in een cookie te zetten?
De cookie wil ik gebruiken om je ingelogd te houden op een forum.
Ik zat zelf te denken om de gebruikersnaam in md5 erin te zetten, en het wachtwoord in md5. En dan de cookie na een week ofzo laten verlopen. Wachtwoord erin is misschien niet slim, maar ik moet op een manier toch een controle uitvoeren (anders kan je met een 'valse' cookie ook binnenkomen). Ik denk dat de username in md5 veiliger is dan id, probeer er maar eens achter te komen welke user je hebt als je een md5 string hebt als username.
Hoe zetten jullie soortgelijke cookies?
NOOIT user èn w8woord in een cookie zetten, ook al is het gehashed, gewoon userid en ip ofzo... kan je checken of de cookie nog op de normale pc staat door dat ip steeds te checken..
Versleutelen met MD5 alleen is niet genoeg - als je het cookie steelt, kun je met de MD5-hashes nog steeds inloggen.
Het wordt pas veilig (of iig veiliger) als je het IP van deze persoon bijhoudt. Elke pagina-access kijk je of de hash van het wachtwoord (en eventuele andere informatie in het cookie) overeenkomt met de gegevens in de database en tevens kijk je of de IP waarmee iemand ingelogd is overeen komt met het IP van iemand die een login-cookie heeft.
Als je het cookie gebruikt om sessies automatisch te starten en te vullen, is dit volgens mij wel "voldoende veilig".
Als iemand een dynamisch IP heeft (omdat deze persoon een ADSL of dialup-verbinding heeft), dan zal dit systeem uiteraard niet werken...
Dus ik zou een extra tabel met IP's aan kunnen maken, waar ik alle gelogde unieke ip's inzet (uiteraard met memid erbij). Dan zet het wachtwoord in md5 erbij, en haal ik op die manier het bijbehorende ID uit de db en controleer dan of het allemaal klopt?
Want het kan zijn dat iemand niet thuis is (ik heb dat ook hier met sima, school en thuis en ik kan op beide ingelogd blijven), en diegene toch ingelogd wil blijven. Zit ik zo in de goede richting?
Trouwens FangorN, in Nederland hebben ADSL gebruikers ook een vast IP, alleen nog de dial-up connecties hebben een dynamisch.
Dit laatste IP hoort thuis in de login-tabel waarin ook username, password, userlevel enzo staan. Daarin maak je dan een kolom last_login_ip aan ofzo.
Je kunt dan maar vanaf 1 PC tegelijkertijd ingelogd zijn... maar dat lijkt mij niet heel erg ongebruikelijk?
Het zal altijd zo zijn dat gebruiksvriendelijkheid opgeofferd moet worden voor betere beveiliging, of andersom. Aan jou de keuze of je IPs logt, of niet.
Je zou inderdaad een soort van koppeltabel kunnen maken die bijhoudt via welke IPs er allemaal een keer succesvol is ingelogd - dat kan.
Maar dat maakt de zaak er niet overzichtelijker op, en het lijkt mij verstandig om loginmechanismes zo simpel mogelijk te houden, maar wat jij voorstelt is niet eens zo'n gek idee.
Het is echter nog steeds geen oplossing voor mensen met een dynamisch IP... Dynamische IPs zijn echter niet geheel dynamisch - de eerste twee of drie delen van het IP zullen doorgaans vast zijn als je via dezelfde provider op het Internet zit. Je zou met deze groep gebruikers dus rekening kunnen houden door alleen de eerste twee of drie getallen te controleren... Je offert daar wat veiligheid mee op, maar je systeem wordt wel flexibeler / gebruiksvriendelijker.
Oke, ik denk hoe ik 't ga doen.
Ik maak een extra veld bij de tabel Leden met last_ip ofzo, daar zet ik het gelogde IP in. Bij het binnengaan van een pagina controleer ik over het IP anders is bij die persoon dan het IP in de database. Zoja, verwijder eventuele sessie, delete cookie en laat opnieuw inloggen, zonee, doe niets (evt. ververs cookie).
Op elke pagina controleer ik het IP uit de cookie en het md5 wachtwoord uit de cookie en kijk of dit matcht met de gegevens uit de database. Anders is die persoon niet ingelogd en moet ie dus opnieuw inloggen.
Bij een inlog (waarbij de optie aanstaat dat je ingelogd wilt blijven) wordt je IP en wachtwoord (md5) in een cookie gezet en uiteraard de sessie gezet.
Euh, waarom zou je het IP opslaan in het cookie? Deze kan dan toch afwijken van iemand zijn echte IP? Controleer het IP met $_SERVER['REMOTE_ADDR'] (of een wat uitgebreidere variant).
Als je alles wat je controleert in een cookie zet, dan ben je nog steeds even ver als voorheen - als iemand de inhoud van een cookie kan overnemen, is je beveiliging al om zeep...
Je moet juist een beveiligingsmechanisme hebben dat "op meerdere poten steunt" dan enkel een cookie. Alleen een cookie is niet veilig genoeg.
Dark_Paul, gebruikersnamen en wachtwoorden sla je niet op in een cookie. Je houdt hooguit het gebruikersid bij en het ipadres en wellicht het tijdstip van inloggen. Je kunt natuurlijk ook een controlegetal (bijv. md5(time())) bijhouden.
Nu snap ik helemaal niet meer wat ik in mn cookie moet zetten
Je ziet op veel fora dat je ingelogd kan blijven, en ook hier op Sitemasters. Dus wat zou ik in die cookie kunnen zetten om iemand ingelogd te houden?
Het moet zo zijn, dat als de cookie is gezet, de waardes hiervan worden vergeleken met de DB en die persoon dan ingelogd is (tenminste, dat lijkt me het meest logische om te doen).
Misschien id en een unieke hash die voor elke persoon anders is? Geeneen beveiliging zou je zo 100% waterdicht kunnen maken lijkt me.
Ik zat te denken als hash een md5 van het wachtwoord. Als je de cookie dan hebt, kan je nog vrij weinig met de info (afgezien van ingelogd blijven ).
Aangezien md5 bijna onmogelijk om te keren is, lijkt me dit redelijk veilig (of heb ik het fout). Ik denk ook de tijd en IP van de laatste login erin zetten.
Dan in de DB het laatst ingelogde IP en laatst ingelogde tijd zetten, en controleren of die kloppen. Dan heb ik dus 4 dingen waarop in controleer. Als je een van de 4 veranderd, kom je niet binnen.
Dat gaat niet werken.. Mensen met een dynamisch ip adres gaan het niet fijn vinden! Zolang je in elk geval maar geen wachtwoorden en het liefst ook geen gebruikersnamen toevoegd. xSc heeft naar mijn mening gelijk. Natuurlijk verschillen de meningen hierover redelijk