In <pan.2011.01.22.15.39...@gmail.com>, Camaleón wrote: >On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote: >> In <pan.2011.01.21.12.44...@gmail.com>, Camaleón wrote: >>>Using cookies for tracking/ >>>identifying the user's session can be replaced with another methods or >>>can require additional security measures for verifying the authenticity >>>of the client. >>> >> Do you have a concrete proposal that is simpler than using HTTPS? > >I wish I had.. sessions carried at server side, hidden fields in forms or >variable uri encoding were the common methods used in the past. > >Cookies are insecure by their own nature and fail to provide a proven >mechanism for uniquely identifying users. You can "hide" (by encrypting >the file) the content of the cookie and you'll avoid remote side >hijacking when someone is sniffing the connection, but the root of >problem still remains: should the "hijacker" has physical access to the >computer I guess he can also impersonate the login session (someone in >the know may want to correct this statement). > >Or just think about removable flash drive devices with portable versions >of the browsers; the owner logins into his online account (facebook, >gmail, whatever...), check the "remember me" option and keeps the full >session encrypted via https (not just the login part). Another user with >access to the flash drive could copy the whole content of the data and re- >use (hijack) the cookie that holds the session id.
Cookies that allow the user to bypass a security measure are often aggressively timed out and/or cleared server-side, preventing this from happening in practice unless the first user authorizes it. Physical access to the same hardware in a roughly 5 minute window also allows one to impersonate another user on a Kerberos network; that's not generally considered insecure. >What I was trying to expose here is that http is a protocol designed >mostly for single-user sessions in mind and todays online services are >powerful enough to require enhanced security measures that current http >protocol specs are not always ready to provide. With cookies, we're >applying "patches/bypasses" but not a definite solution to the problem. Does a session need to last longer than a TCP/IP connection? If so, the sides would have to exchange session identifiers in a way that is quite similar to using cookies. For details look how SSL/TLS allows reusing an existing session on a new TCP/IP connection. There might be a better solution, but it would look very similar to cookie use under a well-considered cookie policy. >Maybe is just we are not using the "right" tool for the job... If a session only needs to last for the length of a TCP/IP connection, then we are almost certainly using the wrong approach, but we'd likely still want HTTP cookies for storing non-sensitive data over long periods of time. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
