SitePoint Sponsor |
|
User Tag List
Results 26 to 34 of 34
-
Dec 5, 2008, 22:22 #26
- Join Date
- Oct 2004
- Location
- world
- Posts
- 128
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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 !
-
Dec 6, 2008, 05:18 #27
- Join Date
- Jan 2008
- Posts
- 203
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 6, 2008, 10:04 #28
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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.
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.
You mean because you have to do an extra query to the users table? Strictly speaking, yes, but in practice that is negligible.
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.
-
Dec 8, 2008, 13:48 #29
- Join Date
- Mar 2005
- Posts
- 94
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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 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.
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.
-
Dec 8, 2008, 14:10 #30
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 8, 2008, 15:28 #31
- Join Date
- Mar 2005
- Posts
- 94
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Dec 8, 2008, 15:57 #32
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 8, 2008, 16:31 #33
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.
-
Dec 9, 2008, 06:57 #34
- Join Date
- Mar 2005
- Posts
- 94
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Bookmarks