[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.

You can probably implement what you're thinking with Javascript and client-side storage, perhaps with WebCL for crypto computation 
(although Javascript is probably good enough now).  Store your authorization tokens locally, public key based or not, then allow 
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.
> Greg


More information about the FoRK mailing list