[FoRK] DNT: another example of "you can't make this shit up"
Stephen D. Williams
sdw at lig.net
Tue Oct 16 15:10:22 PDT 2012
On 10/16/12 6:18 AM, Gregory Alan Bolcer wrote:
> You can forge sessions and steal cookies. Persistence of identity means there's just a cryptographic correlation between the two
> separate accesses. Web sessions have very specific formats and meanings, most of which isn't needed to provide sub-resource access.
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.
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.
> Simply the problem I was solving was a couple things. First, guaranteeing that a user had paid for access without checking with a
> centralized server or a db lookup. Second, eliminating the use of passwords and user accounts and registration. Third,
> amortizing the "pain" of a purchase by reducing the steps to do a secure payment and then being able to transparently maintain the
> access tied to the payment even over time and repeated visits. Fourth, hiding the user identity from the content provider so that
> they never see identifying information, aka cash, while still providing a guarantee.
> It's automated provisioning micro-access.
By generating and importing PKI certificates? That's a heavyweight way to do it. There's no reason to muck with the browser
certificate store, unless you disable cookies and your users don't already have a client certificate.
Signed data packets is the way to do this. Because of browser security, you'd normally have to include a call to another server of
some type even to get access to authorizing cookies. But you could do that once and then just get the cookie from then on. Many
systems work like this.
You could even do it via DNS if you're clever, using fast UDP transactions.
> On 10/16/2012 12:04 AM, Stephen D. Williams wrote:
>> What is "persistence of identity"? Isn't that just a "session"?
>> Identity isn't just a name, it is a unique identity that may have some
>> degree of identification and disambiguous characteristics. A session
>> should have its own identity. If you want to associate some access with
>> the session, then the identity of the user may be how you choose what to
>> show but the session is what is being matched between transactions.
More information about the FoRK