[Opensource] passwd in cookie

[Tino Dai]

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/