tracking session between two server

[dvddesign]

is it ok ? to use cookie insted of session ...in public pc (cybr cafe) . If the user
forgot to logout(may close the webpage,restart..etc not logout) and someone use that pc and go to the site ...he can access without authentication!

As I told ..I know mysql can be use ..but any other professional solution !

[ionix5891]

is it ok ? to use cookie insted of session ...!

Grrrrrrr

repeat after me

sessions are based on cookies
sessions are based on cookies + 2
sessions are based on cookies + 3
..
sessions are based on cookies + n
...


that'll clear a lot of confusion

[kyberfabrikken]

But now some XSS hole means that I'm able to steal very sensitive
information, both the username and password. Then use them to set that
cookie's value on my computer. Further more, depending on how this data is
stored in the cookie, I can even try to crack the password with some rainbow
tables.

True. But if the client is compromised, you'd have these problems anyway. It would be a good idea to store a hash rather than the user/pass in clear text. This is actually safer than a session-based authentication, because you never send the password over http, making package sniffing impossible.

So basically is not about storing data on the server side, is about about storing
temporarily data on the server side?

I really don't see the advantages of client side storage over server side storage,
so please elaborate a little bit.

Yes, you can put it that way. Benefits are plenty, but rather abstract. But to name a few: Reducing the scope of state, you make the interface more transparent, which means that testing get easier. It's basically the same principle as to why global variables are bad, but on a larger scale. Since the interface doesn't rely on your proprietary protocol, it becomes easier for people integrating with your application. For example, spiders and such.
If state is completely client side, it becomes trivial to scale your web server by simply having multiple machines behind a proxy. It also allows http-level caching, which can greatly improve performance on both the server side (no needless rendering) and the client side (no need to repeat a request, if you have it in the cache).
And of course, it means that you don't need to worry about timing sessions out.

And I can't at all see how this is session hijacking proof. If I snatch your session I'm logged in as you. It even looks like it's a pretty valid cookie. Unless you at the same time validate with a session-id or so. But the only differens is that I have to steal two cookies. Or what am I missing her?

If there is no session, there is nothing to hijack. I'm suggesting that each request carry the login credentials. The way session-hijacking works, is by fooling the victim to authenticate on a known session.

The idea of not using server side session is appealing but surely the checking/processing each request would be inefficient compared to accessing $_SESSION or whatever?

You mean because you have to do an extra query to the users table? Strictly speaking, yes, but in practice that is negligible.

And what happens if the user doesn't use cookies.

Fair point. I usually prefer http-authentication, since this is supported by almost any http-client. Most commercial outfits dislikes it though, since you don't have control over the design. So you could use http-authentication as a fallback-scheme.

[elias]

A Secure Cookie Protocol (PDF) describes how to create a tamper proof cookie.

wonder why no one mentioned your great link.
also read the "fu et al" which was referred:
http://pdos.csail.mit.edu/papers/webauth:sec10.pdf

Not necessarily true. You only have to verify the cookie on non safe methods (eg POST etc).

not precise or wrong. (no offense)
you'll verify the cookie token on every request, to verify
expire time and additional data. it's verified against the
(secret) server key.
you need the users credentials only once on login, just
like in an session based authentication scheme.

If there is no session, there is nothing to hijack. I'm suggesting that each request carry the login credentials. The way session-hijacking works, is by fooling the victim to authenticate on a known session.

leaked credentials are worse than a hijacked session,
because the don't expire and are probably usable in
more places. so easy to look into the cookies folder
and test the creds in the bookmarks.
hashing them is neat but not necessarily safer.
a token based authentication is much better, imho.

[kyberfabrikken]

hashing them is neat but not necessarily safer.

How is the removal of one possible attack vector (packet sniffing) not an increase in security?

[elias]

How is the removal of one possible attack vector (packet sniffing) not an increase in security?

you can remove this vector only if you don't use any
network. you can make it only less useful with stronger
encryption/hashing.

as i said, passwords are long term available. if someone
gains access to an encrypted password, he has much
time to decrypt it. if you encrypt wrong, like using
simple md5 hash, you got a problem with rainbowtables.

at the bottom line security is a work/complexity tradeoff,
do what your application demands.

[kyberfabrikken]

you can make it only less useful with stronger encryption/hashing.

But surely you would agree that it's better to send a hash of the credentials, than to send them in clear text?

[Ren]

not precise or wrong. (no offense)
you'll verify the cookie token on every request, to verify
expire time and additional data. it's verified against the
(secret) server key.
you need the users credentials only once on login, just
like in an session based authentication scheme.

Well its just a comparison which is what I meant, rather than breaking the cookie value apart and verifying the signature is valid.
Much like web accelerators/reverse proxies do when caching a response with Vary: Cookie header. They have no idea how the cookie is created just make sure the values are the same before it replies with the cached content.

The expire time on the cookie, and the item in the cache should be the same. So wouldn't have to check the expire time. So the cached item always expires at the correct time (or earlier), so even if altered the expires on the cookie on the client, it would still cause a cache miss.

[elias]

But surely you would agree that it's better to send a hash of the credentials, than to send them in clear text?

as you describe it: yes, but still bad.

Well its just a comparison which is what I meant, rather than breaking the cookie value apart and verifying the signature is valid.
Much like web accelerators/reverse proxies do when caching a response with Vary: Cookie header. They have no idea how the cookie is created just make sure the values are the same before it replies with the cached content.

ah ok, makes sense now.