SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 34 of 34
  1. #26
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    world
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    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 !

  2. #27
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dvddesign View Post
    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

  3. #28
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Amenthes View Post
    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.

    Quote Originally Posted by Amenthes View Post
    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.

    Quote Originally Posted by tdolsen View Post
    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.

    Quote Originally Posted by old_iron View Post
    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.

    Quote Originally Posted by old_iron View Post
    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.

  4. #29
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren View Post
    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

    Quote Originally Posted by Ren View Post
    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.

    Quote Originally Posted by kyberfabrikken View Post
    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.

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elias View Post
    hashing them is neat but not necessarily safer.
    How is the removal of one possible attack vector (packet sniffing) not an increase in security?

  6. #31
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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.

  7. #32
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elias View Post
    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?

  8. #33
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elias View Post
    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.

  9. #34
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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.

    Quote Originally Posted by Ren View Post
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •