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. 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. The same happened with e-mail: e-mail servers are not well-suited for handling 1 GiB of data attachments (neither Gmail provides such option, attachments are limited to 20-30 MiB) because of e-mail's own definition and we have to use alternative methods (ftp, direct links to online storage sites...) for this. Maybe is just we are not using the "right" tool for the job... > Keep in mind that IPs don't identify users -- proxies and reverse > proxies mess that up. Keep in mind that it is difficult to serialize > requests; users that are fans of multiple tabs and/or windows may have > requests that overlap or interleave with other requests. What can be done "now"? Of course, always use encryption when dealing with sensitive data and if we are using "cookies" to store this data (like session ID) apply additional steps that require a second verification of the user and not just trust in the "session ID". For instance, once the user has been logged in and the cookie has been set, add a "mark" -kinda counter/timestamp flag- on the server side that enforces the user to relogin when different session is requested/ detected, from another IP/another browser/etc... Yes, this can be annoying if the request is valid but I prefer a bit of annoyance than getting my account stolen. <mode fake-guru on> I think in a near future, "cloud" services will require the use of small VPNs between the provider and user to ensure a correct management of the user's data, security and encryption so private and public information will be kept under two complete separate scenarios. </mode fake-guru off> Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.22.15.39...@gmail.com
