Jared Farrish wrote:
On 5/29/07, Stut <stuttle@xxxxxxxxx> wrote:
Don't get me wrong, I don't want to discourage anyone from thinking
about ways to improve it, but personally I consider this issue done to
death.
Well, I think the difference is that you send one key (a session
identifier)
and hash on user agent report, while I send an authentication key and a
secondary hash key stored in cookies. I'm sending only nominally more
information than you are, so I don't think there's THAT much difference
between what we're saying here. As a lot of users would store session id's
as cookies, and fall back to a query string id, like I said, I don't see
much of a difference in our approaches, except you don't seem to think mine
is acceptable since it's not a "session" id.
That's not what I'm saying. My basic question is why send the "secondary
hash key" to the client when it doesn't need it? Use the authentication
key to identify the users data, then get the "secondary hash key" from
that data. The browser never needs to see the hash, and from a purist
security point of view it could potentially reveal more about your
security methods than you need to.
If you supply the salt (instead of relying on it being provided, vis a vis,
user agent report), and store that in a cookie on the client, and then that
client can't reproduce an accurate, unchanged version of that cookie, what
change in either the salt and/or the auth id would make this approach
unacceptable (and not break the authentication)? I see major web firms use
But the point here is that both pieces of information required to
authenticate that client are stored on the client. If someone can get
one of them they can get the other, so it's no more secure than just
accepting the one cookie without bothering to authenticate it in any way.
cookies all the time, so I'm not sure why there is a bias against cookies,
besides a user that doesn't support cookies in the first place (which is a
real concern, I admit).
I have nothing against cookies at all, but I think the line between
cookies and session data is pretty clear.
Cookies should be used to...
a) remember a user between sessions (but not authenticate them)
b) remember a session ID during a session
c) remember user preferences for anonymous users, or where there is no
such concept as users on the site
Sessions should be used for everything else. If you're finding that
you're storing huge amounts of data in cookies, switch to using
sessions. If you find that you're storing so-called "sensitive"
information in cookies, switch to sessions.
I remember a poster on a wall of a tech dept my friend worked for that
had a
faux-advert for a "security dongle" for a computer. Essentially, it was a
rubber stopper that was put on a power cable that provided a "100% secure
air gap."
Whether it's been settled or not, I'm not nearly as played out on
discussing
it (especially if I'm not getting aspects correct) as I am about browser
bickering, OS wars, and all the other "dispassionate" discourse currently
"enlightening" the internet. At least with security, there's some known
benefit to discussing it!
I'm more than happy to discuss it, but please tell me you got the point
about whatever extra security is possible is likely to have been added
by the majority of web application platforms, including PHP.
I'm all for talking about it and seeing if there is a better way, but I
also know that people far smarter than me have been talking about it for
over 20 years, and what we have is what they've come up with. Ignoring
the other possibilities like client certificates there's not really
anything more you can do without introducing the possibility or even
likelihood that the user experience will be shafted.
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
