Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
The stupid question is the question not asked
 
PerlMonks  

Re: Re: Re: The sound of one cookie (not) authenticating

by sutch (Curate)
on Apr 03, 2001 at 17:12 UTC ( #69290=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: The sound of one cookie (not) authenticating
in thread The sound of one cookie (not) authenticating

Right, hidden fields are not secure. But Hero Zzyzzx was not concerned about secure sessions (I assume he would handle that through SSL). Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

I don't understand how computing a hash will prohibit sessions from being transferred with URLs. Is the server or the browser going to compute the hash? If the browser, then JavaScript is required (and I believe the issue is not requiring the customer to use cookies, and possibly other optional browser features like JavaScript). If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID).


Comment on Re: Re: Re: The sound of one cookie (not) authenticating
Re: Re: Re: Re: The sound of one cookie (not) authenticating
by arhuman (Vicar) on Apr 03, 2001 at 17:31 UTC
    Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

    Ok I may have missed the question, it thought it was What's the best way to avoid Joe Blow having access to the original shoppers cart?.


    I don't understand how computing a hash will prohibit sessions from being transferred with URLs

    The hash use is only to one way to secure a parameter (verbatim from my post)
    A parameter hashed this way can't be used in another session nor faked.


    Is the server or the browser going to compute the hash?

    The server, beccause only the server knows the 'private value'...


    If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID)

    As the hash value is bound to an id session you just can't use it with another session !
    So you can't reuse and old hash value nor even compute it (if you know your id session) to feed it to the server as you don't know the private value...

    "Only Bad Coders Badly Code In Perl" (OBC2IP)
      I still don't see how this prohibits sessions from being used by another browser. Maybe there is something obvious that I am missing. arhuman, can you please clarify this for me?

      What information is used in the hash?

      If the information in the hash is not directly tied to the browser (such as IP address, browser name), I don't see how a server can determine if the "incorrect" browser is requesting the session.

      If only the session key and some private value is used in the hash, how does the server determine if the hashed value came from the browser that it was originally sent to or some other browser?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://69290]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (9)
As of 2014-04-19 10:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (480 votes), past polls