Ashley Sheridan wrote:
> On Mon, 2010-03-29 at 12:24 +0100, Ben Stones wrote:
> 
>> Hi,
>>
>> I'm just wondering whether there are any apparent security concerns I should
>> be aware of when using sessions in my PHP scripts. I understand that
>> sessions are tracked with an individual user via a session ID which is
>> stored in a temporary location on the server, as well as a PHPSESSID cookie
>> assigned to the end user's client, but the server my website is hosted on
>> (and which I'll be developing my PHP script on) doesn't allow you to create
>> a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
>> the server can generate a session ID for the end user when I call the
>> session_start function? So do I still need to call session_regenerate_id for
>> security purposes when an end user has entered the correct login credentials
>> - would this be necessary since you cant set a session ID via the URL?
>>
>> Thanks,
>> Ben.
> 
> 
> Just setting a URL variable won't actually create a session, you have to
> use the PHP session functions to create one.
> 
> Using session_regenerate_id() won't do that much for security. If you
> are really worried, then consider a security certificate. Even a
> self-issued one is better than nothing, and you can generate these for
> free.

worth noting that you can also issue client side ssl certificates to
your users; 100% secure, self-signed thus free, either by creating a
pki12 w/ php or by using the html KEYGEN element - the ssl cert installs
directly in the users browser. You can use the subjectAltName attribute
of the certificate to save a users unique id.

And thus, 0 click login, perfectly secure auth all done through https -
further meaning you can completely negate sessions/cookies and all the
related insecurities.

further still, you can boot this up to foaf+ssl giving users one unique
web id for themselves, and in full control of there own profile / login
etc; (like openid done right and one steriods)

Will be the defacto industry standard in a couple of years, so may as
well adopt early.

Regards!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to