Again, "It's not perfect, but I don't think anyone has come up with a better
way."
It's called session hijacking, and it is a great reason to use SSL. However,
there's still the issue of cross-site scripting, which can really only be
prevented by smarter coding.
Even then there are issues. For
On Fri, May 30, 2003 at 11:01:26PM -0700, Evan Nemerson wrote:
> Send a session ID to the user in a cookie, then lookup that ID in a database
> on the server. It's extremely difficult to guess random session ID's (don't
> just increment them!), and if you have a session timeout, you're pretty muc
Send a session ID to the user in a cookie, then lookup that ID in a database
on the server. It's extremely difficult to guess random session ID's (don't
just increment them!), and if you have a session timeout, you're pretty much
set.
It's not perfect, but I don't think anyone has come up with
The short answer is that if you're worried about security, don't store a uid
and pwd in a cookie on the client... banks don't do it, for example.
It's also common for the uid to be remembered, but not the pwd.
>From what I can see happening on the "big sites", you give the user the
option to be r
I see some posts here that say storing a username or encrypted password in a
cookie is not secure. If so, then what's a more secure way to allow users to
be "remembered" using a cookie so that they don't have to log in every time
they come to the site? What do you store in the cookie to authenticat
5 matches
Mail list logo
