Mijn eerste vraag gaat over cookies, als ik een cookie plaats voor het inloggen dan doe ik dit met een hash en de gebruikersnaam, nu zou ik daar iets aan willen toevoegen functie zodat ik die niet telkens bij het openen van een pagina moet laden, maar ik vraag me af of iemand die functie dan kan wijzigen om zo bepaalde persmissies te krijgen die hij/zij eigenlijk niet mag hebben.
@WD Freak, bedankt voor je reactie, maar ik wil dat de fieldset (dus de hele witte blok) rechts geplaatst wordt ipv links de tekst mag blijven zoals hij is. Misschien niet helemaal goed gemeld.
Kan je uitleggen wat je precies bedoelt met: 'nu zou ik daar iets aan willen toevoegen functie zodat ik die niet telkens bij het openen van een pagina moet laden'?
Afhankelijk van de functie van een gebruiker krijgt deze permissies: ik heb 3 soorten gebruikers: Guests (Rang 0), Users (Rang 1) en Admins (Rang 2). Bij het laden van een pagina/ refreshen van een pagina ga ik nu steeds ophalen uit de database welke Rang deze persoon heeft om dan de nodige zaken te laten verschijnen op de pagina. Ik vraag me nu af of ik bij het inloggen bij de cookie gewoon de rang kan mee opslaan, zodat deze niet telkens opgehaald worden. Maar daarvoor moet ik zeker zijn dat je niet in de cookie zelf de Rang kan gaan aanpassen van bijvoorbeeld 1 naar 2.
Cookies zijn niets meer dan tekstbestanden die bij de client opgeslagen zijn, en zijn tevens aanpasbaar.
Dus het is zeker niet aan te bevelen om hier data in op te slaan die toebehoren bij bepaalde rechten.
Een userID en een uniek hash-id die niet afleidbaar is van andere informatie is het enige wat voor een inlog-cookie interessant is.
Bij het laden van een pagina/ refreshen van een pagina ga ik nu steeds ophalen uit de database welke Rang deze persoon heeft om dan de nodige zaken te laten verschijnen op de pagina.
Dat is sowieso een goed idee, anders blijven deze permissies "hangen" totdat een gebruiker is uitgelogd. Het is daarom ook niet verstandig om deze informatie op te slaan in je sessie, je hebt dan namelijk hetzelfde probleem.
Sla enkel het user id op in je sessie, en haal je user credentials bij elke page refresh op en stop deze in een user-object die elke page-access opnieuw wordt opgebouwd.
Een userID en een uniek hash-id die niet afleidbaar is van andere informatie is het enige wat voor een inlog-cookie interessant is.
Ik zou een user id niet (meer) in een cookie opslaan.
Als je op een vaste PC een login wilt onthouden kun je volstaan met een cookie waarin enkel een hash staat. Je database kan de rest onhouden (hash ter identficiatie, IP, houdbaarheid èn user id).
Wat is er mis met het opslaan van een UserID. Het voorkomt in ieder geval dat er onverhoopt (door een programmeerfout) twee dezelfde hashes uitgedeeld zijn, waarbij iemand opeens ingelogd is onder een andere gebruiker.
Dubbele hashes zouden niet voor moeten komen uiteraard, en als je echt heel paranoia bent controleer je hier op net zolang totdat je een nieuwe unieke hash hebt gegenereerd. Daarbij ben je dan niet ineens ingelogd als een andere gebruiker als je ook een IP-check doet. En deze hashes zouden een beperkte levensduur moeten hebben, en dan zou je nog een re-hash kunnen doen bij succesvolle door-/inlog.
Het is simpelweg niet nodig om een user id toe te voegen, in die zin dat het veiliger zou zijn, wat het niet is. Of je deze informatie nu in het cookie stopt of in je database maakt hiervoor niet uit. Wel ontsluit je (op voorhand) minder informatie als je het user id niet in je cookie stopt. Je maakt hiermee je "attack surface" kleiner, en je oplossing minder complex. Wat in zekere zin de veiligheid ten goede komt.
Je hanteert ook een beetje een drogredenering, je zegt in feite: als het loginmechanisme niet veilig is kun je zomaar inloggen als iemand anders!
