NYCPHP Meetup

[Chris Bielanski]

Only solution I've ever seen devised for this is a moving-target encryption.
Public key handshake (within SSL) leads to an ever-changing series of
private keys devised by your own proprietary method. Every transaction
(every page) has a new key. The numerical application is left as an exercise
to the reader. ;)

No, it's not pretty. Yes, it makes Sterling and other beasts like it break
out in cold sweat.

Otherwise, yeah, get it off HTTP and on to your own protocol. That solves
the problem most handily.

~Chris

-----Original Message-----
From: Hans Zaunere [mailto:hans not junk at nyphp.com]
Sent: Tuesday, January 27, 2004 3:38 PM
To: NYPHP Talk
Subject: RE: [nycphp-talk] sessions and application security


> One thought is to use both a token in the url and database sessions, 
> where the token in the url is a checksum of the database session, and 
> possibly vice versa. That way I can check both.  If I have a 
> checksum in both, then I can compare the checksum.  Hmm.

Good ideas, but even so, if someone can get that key on the browser,
he's in.  Again, it's the browser - but perhaps rotating session keys
can help - which could at least detect if a hijack was *attempted* and
then shutdown the session.

> Thoughts, suggestions, or even better what is the "best" way 
> to do this?

Don't use a web browser :)

H
_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk

>From hans not junk at nyphp.com  Tue Jan 27 15:55:48 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.exch011.intermedia.net (unknown [64.78.21.3])
	by virtu.nyphp.org (Postfix) with ESMTP id 4A6A6A8771
	for <talk at lists.nyphp.org>; Tue, 27 Jan 2004 15:55:48 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] sessions and application security
Date: Tue, 27 Jan 2004 12:55:46 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F8752B219 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] sessions and application security
Thread-Index: AcPlFlqng//tD47gRza/wQOazTgU6AAAWUSg
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2004 20:55:48 -0000


> Only solution I've ever seen devised for this is a=20
> moving-target encryption.
> Public key handshake (within SSL) leads to an ever-changing series of
> private keys devised by your own proprietary method. Every transaction
> (every page) has a new key. The numerical application is left=20
> as an exercise to the reader. ;)

I had kicked around some sequencing sessions, modeled after TCP's
SYN/ACK sequence numbers - but using the SSL keys... now
that's-a-good-idea.  I'm even thinking...  depending on your platform,
you could reach down the network stack and just grab the real TCP
SYN/ACK numbers.  But probably not doable in pure PHP :)

H