You keep repeating what I've already said. That's what the *sigh* was about.
But, I was hasty in sighing as you're right in how important it is to
clarify to the absolute limit on this subject. Sorry about that!
Far to many programmers are completely oblivious when it comes to
hacking methods.
And, as you said, there's no way to make a cookie secure... Only a bit
more secure. Everything is in shades of gray.
Truthfully, I've never ever built a site or part of a site that relies
on cookies for anything. Except for the more or less default PHP
configuration for sessions to use cookies for the SESSID.
Mike
Stut skrev:
Mikael Grön wrote:
As I said.
Cookies being completely insecure is as valid as Cookies not being as
secure as Sessions.
Sessions are more secure than cookies, but only in so far as the
actual data stored in a session is never sent to the client.
... *sighs*
I'm not sure what that's supposed to mean. This is a serious topic,
and the lack of understanding of it that too many PHP developers
suffer from is part of the reason PHP is getting a bad security
reputation.
Though, there are ways to make cookies more secure, for example by
storing copies of them with timestamps in a database and matching
values before allowing users to pass... But that's more or less
exactly what Sessions do, so there's really no use of Cookies for
authentication.
There is no real way to make cookies secure. Anything you do needs to
be reversible and so can be brute-forced. The best approach to take
IMHO is to use cookies for session IDs and identification between
visits. *Never* authenticate someone based purely on a cookie, and
*never* track user status in cookies.
Oh, and to correct one other thing, cookies will disappear when you
close the browser if you don't give them an expiry time. This is how
the session ID cookie works.
-Stut
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
