[PHP] alleen eerste koekje wordt gegeten

[Verwijderd]

hallow

ik heb deze code:

PHP:

  setcookie("_gebruikertype", $gebruiker["gebruikertype"]);
  setcookie("_gebruikersnaam", $gebruiker["gebruikersnaam"]);
  setcookie("_gebruikerid", $gebruiker["gebruikerid"]);

maar alleen de '_gebruikerid' komt in een koekje terecht. (en php eet het laatste koekje als eerste op)
als ik de gebruikersnaam setcookie als laatste doe werkt die dus juist als enige..
alsof ik maar een koekje mag setten .. php zonder honger?

misschien belangrijk: ik heb apache2 en php4 onder mac osx ...

wie helpt mij uit de brand?

[seweso]

Php denkt met je mee! Je hebt namelijk alleen het gebruikers-id nodig!

[ Voor 85% gewijzigd door seweso op 09-04-2004 19:32 ]

[Verwijderd]

verhip je hebt wel een punt

maar het is wel makkelijk om overal de username op te kunnen vragen ipv elke keer weer een query te moeten doen

en het moet gewoon werken

[seweso]

Verwijderd schreef op 09 april 2004 @ 19:37:
verhip je hebt wel een punt

maar het is wel makkelijk om overal de username op te kunnen vragen ipv elke keer weer een query te moeten doen

en het moet gewoon werken

als het tijdelijk is dan moet je het in de $_SESSION array douwen. Cookies moet je zo klein mogelijk houden, want die informatie word bij elke pagina opvraag naar je server gestuurd....

[Verwijderd]

tjah.. true, maar ik heb het niet zo op sessions ..
maar als ik hier niet uitkom kan ik het natuurlijk wel weer eens proberen

en ik bedacht me dat ik ook meerdere vars in een var kan proppen, en dan een uitelkaarhaal functie .. maar toch.. ik vind dat het gewoon moet werken, tis een principe kwestie he

[djluc]

Verwijderd schreef op 09 april 2004 @ 19:43:
tjah.. true, maar ik heb het niet zo op sessions ..
maar als ik hier niet uitkom kan ik het natuurlijk wel weer eens proberen

en ik bedacht me dat ik ook meerdere vars in een var kan proppen, en dan een uitelkaarhaal functie .. maar toch.. ik vind dat het gewoon moet werken, tis een principe kwestie he

Is het niet gewoon de array $_COOKIES o.i.d. tegenwoordig? Verder is het opslaan van een username in een sessie bij mij ook zeer gebruikelijk. Daar wil ik echt niet een query aan verspillen.

Waarom heb je eigenlijk iets tegen sessions?

[Johnny]

sessions zijn echt geweldig, als je het eenmaal snapt.

Trouwens, alleen een user_id in de cookie steken is niet zo veilig, want dan kan iedere nerd een ander nummertje in zijn cookie zetten om als iemand anders in te loggen.

Wat ik het handigst vind is om een hashcode achter je user_id te zetten, die hash maak je dan met md5() uit het password/username/user_id of een combinatie daarvan.

Als je een cookie uitleest splits je de userid en hashcode op, haal je de juiste record uit de database, maakt daarmee een hash en vergelijkt ze met elkaar.

[Verwijderd]

Johnny schreef op 10 april 2004 @ 12:00:
sessions zijn echt geweldig, als je het eenmaal snapt.

Trouwens, alleen een user_id in de cookie steken is niet zo veilig, want dan kan iedere nerd een ander nummertje in zijn cookie zetten om als iemand anders in te loggen.

Wat ik het handigst vind is om een hashcode achter je user_id te zetten, die hash maak je dan met md5() uit het password/username/user_id of een combinatie daarvan.

Als je een cookie uitleest splits je de userid en hashcode op, haal je de juiste record uit de database, maakt daarmee een hash en vergelijkt ze met elkaar.

Ik heb dit nooit zo begrepen. Waarom zou je moeilijk doen door een hash te maken van user_id, password, etcetera. Het boeit uiteindelijk helemaal niets. De kans dat iemand een hash raadt wordt er gewoonlijks alleen maar hoger van. Ik reken het even voor:

16³² = het aantal mogelijke md5 strings, een hexadecimale digit, en dat dus 32 keer. Wil je dit met een gewone string een evengroot bereik hebben, dan moet die string 16 tekens lang zijn, want 16³² = 256¹⁶. Kortom, het is meestal beter om gewoon het wachtwoord te gaan raden, en niet de md5 string, want we mogen denk ik aannemen dat de gemiddelde lengte van wachtwoorden op niet meer dan 10 tekens ligt. En zelfs dan, niet alle 256 karakters uit de beschikbare reeks zullen even frequent worden gebruikt.

Wat ik wil duidelijk maken, is dat het helemaal niets mag uitmaken wat er precies ge-md5't is, als het maar een zo willekeurig mogelijke hash oplevert. De hash gaan proberen te raden loont veel minder dan gewoon het wachtwoord proberen te raden. Pas bij een string die gemiddeld meer dan 128 bits gebruikt is het raden van de md5 verstandiger.

Ik gebruik dus gewoon een willekeurige md5 hash als session id, en wat dat verder is, dat boeit eigenlijk niets. Ik zet overigens ook het user_id in het cookie, en vergelijk dat met het user_id uit de sessie.
Eigenlijk ook een beetje onzinnig omdat de kans dat iemand een sessie kan stelen al zo klein is, maar goed, die maken we dus nogeens een stuk kleiner, gelijk aan een factor die gelijk is aan het aantal personen dat in kan loggen. Zo kun je nog wel verder gaan, maar ik vind een kans van 1:2¹²⁸ wel genoeg. Het is een bizar groot getal. En het raden van een wachtwoord is veel eenvoudiger.

[djluc]

O Johnny, ik had er nog niet eens aan gedacht dat hij op het idee zou komen om daarmee rechten uit te gaan delen

Sessions zijn inderdaad erg handig, maar vooral erg simpel in het gebruik, een array aanpassen kan iedereen toch wel? Alleen op shared-servers zouden er nog gevaren kunnen zitten, als ik het goed heb begrepen? Je zou op één of andere manier een sessie over kunnen nemen o.i.d?

[twiekert]

sessies worden opgeslagen in /tmp. elke lul de behanger op die server kan uiteraard de tmp directory uitlezen, en daarmee de data die jij in de sessies opslaat

[Verwijderd]

twiekert schreef op 10 april 2004 @ 12:45:
sessies worden opgeslagen in /tmp. elke lul de behanger op die server kan uiteraard de tmp directory uitlezen, en daarmee de data die jij in de sessies opslaat

Dat kun je wijzigen in je configuratie, zelfs met ini_set, dus als je gegevens wilt opslaan, kun je dat doen in een directory die een ander niet kan inzien.

[Verwijderd]

nouja de enige lul de behangers die met ssh/telnet op de server die ik gebruik kunnen komen zijn de webhosting-luitjes en dat zijn aardige knakkers

maarjah sessies he... ik heb ze ooit geprobeerd te gebruiken, maar dat ging volledig mis (weet niet meer waarom). toen vroeg een vriend van me waarom ik geen cookies ging gebruiken.. dat doe ik nu al tijden en ik heb er nooit een nadeel aan kunnen ontdekken. nouja, behalve nu dan dus... dus ik ga nu maar eens pogen weer in de sessies te duiken..

wish me luck

[Verwijderd]

ik heb het probleem al gevonden .. http://www.phpbuilder.com....php?s=&threadid=10206390
is dus een bug in php (in combinatie met apache2) en dat is best lastig, aangezien de gefixte versie er niet is voor osx
maar goed, dan maar serializen die vars

[Johnny]

Verwijderd schreef op 10 april 2004 @ 12:24:
[...]

Ik heb dit nooit zo begrepen. Waarom zou je moeilijk doen door een hash te maken van user_id, password, etcetera. Het boeit uiteindelijk helemaal niets. De kans dat iemand een hash raadt wordt er gewoonlijks alleen maar hoger van. Ik reken het even voor:

[berekening]

Ik was nog vergeten dat ik er ook nog wat random garbage in zet voordat ik het encrypt, iemand die de hashcode wil kraken zal die dan ook moeten weten, en de enige manier om daat achter te komen is brute-forcen, wat ook weer makkelijk te detecteren.

Wat ik wil duidelijk maken, is dat het helemaal niets mag uitmaken wat er precies ge-md5't is, als het maar een zo willekeurig mogelijke hash oplevert. De hash gaan proberen te raden loont veel minder dan gewoon het wachtwoord proberen te raden. Pas bij een string die gemiddeld meer dan 128 bits gebruikt is het raden van de md5 verstandiger.

Ik gebruik dus gewoon een willekeurige md5 hash als session id, en wat dat verder is, dat boeit eigenlijk niets. Ik zet overigens ook het user_id in het cookie, en vergelijk dat met het user_id uit de sessie.
Eigenlijk ook een beetje onzinnig omdat de kans dat iemand een sessie kan stelen al zo klein is, maar goed, die maken we dus nogeens een stuk kleiner, gelijk aan een factor die gelijk is aan het aantal personen dat in kan loggen. Zo kun je nog wel verder gaan, maar ik vind een kans van 1:2¹²⁸ wel genoeg. Het is een bizar groot getal. En het raden van een wachtwoord is veel eenvoudiger.

Voor sessies is het inderdaad zo, maar ik heb het niet over het stelen van sessies, maar cookies die niet bij een sessie horen, en "permanent" bewaard blijven.

In zo'n geval moet je dus wel de hashcode ergens op baseren en weer terug kunnen halen om een gebruiker te authenticeren. (tenzij je voor iedere cookie die je wegschrijft een record maakt in je database en daar je random hash in zet.)

offtopic:
Sorry voor de kick, ik lees de reactie van Cheatah nu pas