Cookies worden niet ge'set

[Alfredo]

Ik probeer al enkele dagen simpelweg twee cookies te setten. Om één of andere reden, weigert PHP dit echter.

Uit het login script:

HTML:

<form id="login" action="core/validate_login.php" method="post">

Uit validate_login.php:

PHP:

if( isset($_POST['remember']) )
                    {
                        setcookie("gebruikersnaam", $user, time() + 60 * 60 * 24 * 365, NULL, NULL, NULL, true);
                        setcookie("wachtwoord", $password, time() + 60 * 60 * 24 * 365, NULL, NULL, NULL, true);
                    }
                    $smarty->assign("logged_in", "1");
                    $_SESSION['logged_in'] = 1;
                    $_SESSION['from_login'] = 1;
                    header("Location: /redirect.php");

Ik weet zeker dat de code binnen bovenstaande if wordt uitgevoerd. Ik heb ook al geprobeerd de cookie te herleiden tot zijn meest basische vorm en dezelfde cookie te setten op de index pagina (daar gaat het wel). Ook heb ik geprobeerd met ob_start() en ob_end_flush ervoor te zorgen dat de output buffer weggeschreven wordt voor mijn header(), maar dat deed ook niets.

Iemand die enig idee heeft wat ik fout doe?

[Patriot]

Ik neem aan (gezien de action van het form), dat het PHP-bestand in de map /core/ staat. Is het niet toevallig zo dat wanneer je de path-parameter van cookie op null zet, hij default naar het huidige path (in dit geval dus /core/). Hij is dan niet beschikbaar op /, waar jij waarschijnlijk kijkt of hij bestaat. Kijk eens of het werkt als je al die optionele parameters (dus alle parameters na expires) weglaat.

EDIT:
Quote van php.net:

path

The path on the server in which the cookie will be available on. If set to '/', the cookie will be available within the entire domain . If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain . The default value is the current directory that the cookie is being set in.

[ Voor 35% gewijzigd door Patriot op 26-05-2009 02:07 ]

[RobIII]

Waar hoort mijn topic?
WEB >> PRG

[Alfredo]

Snel antwoord, en nog correct ook.
Ik heb het path gewoon op "/" gezet (heb graag httponly, de rest blijft dus staan) en nu werkt het perfect.

Bedankt!

offtopic:
Sorry Rob

[ Voor 10% gewijzigd door Alfredo op 26-05-2009 02:19 ]

[Cartman!]

Zoek eens een paar topics op over veilig inloggen / sessies. Je slaat nu iemand zn username en wachtwoord op in n cookie en dat is allerminst veilig. Even kort wat wel een goed idee is: na het inloggen genereer je een unieke code (iets randoms) en die sla je op in een cookie en in de database. In de database sla je het userid op bij de unieke code. Je leest daarna de unieke code in van het cookie, zoekt dit op in de database en je hebt de gebruiker gevonden wie erbij hoort.

[Alfredo]

$password is als benaming waarschijnlijk slecht gekozen, maar het is wel degelijk een salted md5 hash. Ik zou de cookie dan ook nog kunnen binden aan het IP adres, maar voor dit (persoonlijk) project is httponly cookies en filteren van gebruikersinput voldoende om XSS attacks tegen te gaan.

[Janoz]

Alfredo schreef op dinsdag 26 mei 2009 @ 13:05:
$password is als benaming waarschijnlijk slecht gekozen, maar het is wel degelijk een salted md5 hash. Ik zou de cookie dan ook nog kunnen binden aan het IP adres, maar voor dit (persoonlijk) project is httponly cookies en filteren van gebruikersinput voldoende om XSS attacks tegen te gaan.

Of het wachtwoord nu plain is of gehashed, maakt niet uit. Het punt van Cartman! staat nog steeds. Er is geen enkele functionele noodzaak om het op deze manier op te lossen. Dezelfde functionaliteit is ook te bereiken met een token zonder betekenis. Sterker nog, het token bied juist meer functionele mogelijkheden.

Daarnaast zijn er veel meer mogelijkheden om de cookies van een gebruiker te achterhalen, zonder XSS attacks, nog los van of je überhaupt 100% kunt garanderen dat alles compleet afgedicht is (Ik durf alvast te garanderen dat er gaten in zitten aangezien je aangeeft dat enkel de input gefiltert wordt.)

[Alfredo]

Op welke manier is een (degelijke) hash minder veilig dan een token? Het idee van het tegengaan van cookies te stelen is niet dat het wachtwoord achterhaald kan worden (zelfs met rainbow tables heb je daar nog de salt voor nodig), maar dat gebruikers zich niet kunnen inloggen als iemand anders.
En in dat geval biedt een token toch ook geen extra veiligheid?

Bij mijn weten moet ik dan uitwijken naar het binden van het IP adres of iets dergelijks aan de cookie, en dat is way overkill voor wat ik in gedachten heb.
Of zie ik iets over het hoofd?

[Cartman!]

Als iemand jouw cookie steelt is ie inderdaad ingelogd onder jouw account (dat is hier op GoT ook zo, het zogeheten TnetID). Echter heeft die 'hacker' daarmee jouw wachtwoord niet, ook geen hash-versie ervan.

Je kunt de gebruiker tijdens het inloggen de keuze geven wel of niet aan ip te koppelen, die optie (en het gekoppelde ip) hou je zelf bij in de database, niet clientside want dan zou het effect weer zinloos zijn.

edit: je kunt zoals Janoz al aangaf nog meer functies toepassen bij eigen sessiebeheer. Je kunt bijv. van te voren instellen wanneer je sessie verloopt of achteraf een sessie op een andere lokatie verwijderen (bijv. je bent in de bieb ingelogd en vergeten uit te loggen, dan kun je thuis die sessie ongeldig maken). Dat daarbij het cookie blijft bestaat geeft niet, de token daarin werkt toch niet meer.

[ Voor 32% gewijzigd door Cartman! op 26-05-2009 14:26 ]

[Janoz]

Alfredo schreef op dinsdag 26 mei 2009 @ 13:42:
Op welke manier is een (degelijke) hash minder veilig dan een token? Het idee van het tegengaan van cookies te stelen is niet dat het wachtwoord achterhaald kan worden (zelfs met rainbow tables heb je daar nog de salt voor nodig), maar dat gebruikers zich niet kunnen inloggen als iemand anders.
En in dat geval biedt een token toch ook geen extra veiligheid?

Omdat je je cookie baseert op bestaande gegevens is hij vanaf de server niet te invalideren. De enige manier voor een gebruiker om een 'remember me' ongeldig te maken is om de bron van de hash aan te passen. De gebruiker zal dus zijn wachtwoord aan moeten passen. Aan de andere kant is hij gegarandeerd overal uitgelogd wanneer hij zijn wachtwoord wijzigd, ookal wil hij dat misschien wel niet.

Dat het wachtwoord niet te achterhalen is omdat de salt geheim is is leuk en aardig, maar met het gehashde wachtwoord kun je (binnen de context van de site) net zo veel doen als met het originele wachtwoord. Het is dus helemaal niet nodig om het te ontcijferen.

Een token daarintegen is heel simpel te invalideren. Gooi hem gewoon weg uit de tabel waaraan verschillende 'remember me' tokens verbonden zijn aan die gebruiker en het token werkt niet meer. Daarnaast kun je ook voor de gebruiker een overzichtje tonen van de uitgedeelde tokens zodat de gebruiker kan zien hoeveel tokens er zijn en wanneer ze gebruikt zijn. Verder kun je per token ook nog wat metadata opslaan op de server. Denk daarbij aan een optionele koppeling aan IP, maar ook aan een commentaar veldje waarin de gebruiker aan kan geven om welk token het gaat ("Laptop" of "computer boven")

Bij mijn weten moet ik dan uitwijken naar het binden van het IP adres of iets dergelijks aan de cookie, en dat is way overkill voor wat ik in gedachten heb.
Of zie ik iets over het hoofd?

Zoals ik hierboven al aangeef. Tokens te gebruiken heeft alleen maar voordelen. Naast dat het security en andere problemen wegneemt maakt het ook nog een enorme berg extra functionaliteiten mogelijk, zonder dat de implementatie lastiger wordt. De implementatie wordt eerder makkelijker. Nu kun je gewoon een random waarde heen sturen en is de noodzaak voor een ingewikkeld hash algoritme weggenomen.

[Alfredo]

Interessant punt, ik ga eens zien hoe ik dat hier kan implementeren.

Bedankt