[FoRK] DNT: another example of "you can't make this shit up"
Stephen D. Williams
sdw at lig.net
Tue Oct 16 17:29:28 PDT 2012
On 10/16/12 3:49 PM, Gregory Alan Bolcer wrote:
> On 10/16/2012 3:10 PM, Stephen D. Williams wrote:
>> Fundamentally, session cookies are nothing more than a random number.
>> Done properly, you can't forge a random number. Cookies shouldn't be
>> able to be stolen for a TLS-enabled session. Otherwise no one would do
>> online banking. If you're talking about a local attack, the cookie is
>> about as exposed as any private key or certificate would be, except for
>> hardware keys.
> You're still thinking like a security guy. Cookies can be stolen. Firesheep?
Firesheep scanned unencrypted traffic looking for open HTTP sessions with cookies. Most web email and other sites at the time
cheaped out and defaulted to or only supported HTTP. Cheap bastards. Although the glaring problem was long known and widely
understood, it took Firesheep to finally made all major web sites finally support and make HTTPS default for all relevant traffic.
It was basically widespread criminal negligence before that. Doesn't apply here. As soon as you are in a TLS session, everything
is verifiably opaque.
Firesheep was the single best thing to happen to the average person's security stance in the last 10 years.
Didn't affect me at all. In that era, I used MySpace, Facebook, and Gmail about one time, saw they defaulted to HTTP, rolled me
eyes, and went back to IMAPS / SMTPS tunneled through certificate-based SSH, same as I've been using for 15 years.
>> As long as they are cryptographically secure, a session cookie could be
>> its own certificate of sorts: Take the current date, add salt, encrypt
>> with a private key and any server with that key can validate. Or take
>> random data and sign it with a private key and any server with the
>> public key can validate. You can clip this to be arbitrarily short and
>> still validate.
> Congrats, you just invented some new IP. Now the next step is to short-circuit the cookies and just use client side certificates.
> Once you fall into that camp, there's a finite number of small things that need to be fixed in how certificates are handled and
> then, we're off onto a brave new world.
Typical security algebra.
A client-side certificate is just a cookie that your browser will give to anybody, at least for the public certificate part.
services to request an authorization check. A modified browser could short cut any need for using an auth server for assistance,
but even when one is needed the local storage of tokens could obviate any database or storage on the auth server. That allows easy
scaling and even seeding ISP or corporate nodes for fast local traffic.
User identity, a la PKI, shouldn't be confused with proof that you are holding an authorization key even if they are both using
public key cryptography. I don't like a lot of things about PKI, starting with ASN.1 and OSI-like X.509 based encoding, but it now
unless it becomes completely broken.
More information about the FoRK