[Opensource] passwd in cookie

[David Herron]

The path packets follow tends to change on every packet transmission.
TCP/IP was designed to automagically route around breackages in the
network;  in case the Russkie's nuked one router, other routers would kick
in and the launch commands would still get to the missile silo's.  Well,
okay, that's what BBN sold DARPA on when they funded the Internet ... who
knew it would actually be used for music swapping networks and pr0n
gala's??  ;-)

If someone's on a dialup, they don't have a MAC address at all.  MAC
addresses are soley for ethernet-like networks.  On PPP all you have is
the TCP/IP addresses of the two endpoints, and they may even be hidden
behind a NAT firewall anway.  An AOL user doesn't even have IP addresses
since AOL has its own proprietary dialup protocol, that is NOT ppp.  Well,
okay, I dunno fer sher if they don't have an IP address, but AOL doesn't
use PPP.

Oh, and if you want to rely on IP addresses, then what about people behind
NAT firewalls like I am?  Part of the security on my network, in addition
to running Mac OS X and not the virus-ridden fleabag of an OS that
microsoft makes (er.. one of these days I gotta get over that infatuation
with despising microsoft), is to have an SMC Barricade between me and my
DSL connection.  The IP address assigned me by Raw Bandwidth (my DSL
provider) is totally unknown to my Mac, and the IP address on the Mac is
DHCP assigned by the router and is in one of the public free-for-all
sections of IP addresses (like what 10.* became).

I sorta like the idea of sequence numbering.  But .. one of the
requirements is that someone be able to be "logged in" from multiple
browsers.  For example, for the Motley Fool web site and for my.yahoo.com
I'm logged in to both on both my work and home browsers.  And here at home
I have 3 different browsers I use (because each flake on different sites),
so in essence I'm "logged in" from four different browsers.  On both.  So
if you're sequence numbering, then it would have to account for multiple
browsers, which I don't see being workable.  I think the solution may be
in the general direction of sequence numbering.

- David Herron


On Fri, 11 Oct 2002, Tino Dai wrote:

> On Fri, 2002-10-11 at 16:46, Michael Rimov wrote:
> > At 02:07 PM 10/11/2002 -0400, you wrote:
> > >Hi Mike,
> > >
> > >    Actually, I was thinking about this in how the encrypted cookie could
> > >be taken and still not be able to be used. Could we not encrypt the ip
> > >address
> > >  and the mac address into the cookie?
> >
> > Hi Tino,
> >
> > The problem with encrypting the ip address is that each time a laptop user
> > moves around, or a dialup user redials, they're likely to have a different
> > ip.  MAC address would be much more useful, but I'm unaware at how to get
> > it from the Java APIs???
> ok, so for the MAC address, one could use the package that Peter Pilgram
> wrote called JavaUnix or you could use Runtime.exec("") with the
> corresponding commands for the different platforms. It's kind of ugly,
> but it will work.
> >
> >
> >
> > >the problems. Also, a more exotic encryption scheme would be the
> > >different gateways and routers that the packet passes through from the
> > >server to client as part of the encrypted cookie. What does the
> > >community think?
> >
> > Well, backtracing the cookie would take significant time, so the login and
> > logout process could slow to a crawl.  Unless you see a way to do it that I
> > don't?  But either way, I guess the same problems apply here as apply to ip
> > addresses.
> I don't agree Mike. If a laptop redials or loses his/her connection
> somehow, the chances are that the physical path to Expresso will not
> change. Usually, the hardware is still the same regardless of the ip
> address. As a test, does anybody out there have an AOL account (ecckkk)
> that we can test with? And if a laptop moves around, if we get a cookie
> that doesn';t match, we just send the user to the login page again.
> Now, I do agree with you about the tracerouting of the cookie to be
> long and problematic (and I don't have a solution off hand)
> >
> > I'm glad to have thoughts on the replay problem.
> How about in the cookie we have a ascending counter that is encrypted
> and updated on every transaction. So even if the intruder got the
> cookie, the intruder wouldn't know the next number in the sequence.
> >
> > We could also potentially encode a validitity period of, say, one week
> > rather than 90 days.  This could at least narrow the window of replay
> > usage.  I believe time stamping is how Kerberos takes on replay. [Except
> > their's is probably about 30 minutes or so... and 30 minutes for a cookie
> > wouldn't work too well]
> Yes, but Kerberos also has atomic clocks at both ends, and that is an
> unrealistic possibility. But, we could have the cookie expired every 30
> minutes without some kind of transfer of data betwen server and client.
> And at the end of 30 minutes, we could have the cookie be sent back to
> the server with he encrypted ascending sequence for renewal from the
> server. What do you think?
>
> -Tino
>
> >
> >                                                  -Mike
> >
> >
> > _______________________________________________
> > Opensource mailing list
> > Opensource at jcorporate.com
> > http://mail.jcorporate.com/mailman/listinfo/opensource
> > Archives: http://mail.jcorporate.com/pipermail/opensource/
>
>
> _______________________________________________
> Opensource mailing list
> Opensource at jcorporate.com
> http://mail.jcorporate.com/mailman/listinfo/opensource
> Archives: http://mail.jcorporate.com/pipermail/opensource/
>