Re: Let's talk about HTTPS Everywhere
On Fri, 21 Jan 2011 16:14:31 -0600, Boyd Stephen Smith Jr. wrote:
> In <[🔎] pan.2011.01.21.12.44.32@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
Reply to: