[Opensource] passwd in cookie

[larry hamel]

hi,

regarding Tino's suggestion, some questions about the bigger picture of security in expresso: 

if an application is very security-conscious, will that application permit expresso cookie authentication *at all*?   expresso's password cookie is only used after the session is expired, yet the session duration is probably the limit of trust for high-stakes security.

I asked the original question in this thread to see if someone had eliminated the password storage in the cookie.  it is a pretty bad security story that we write the password in the cookie, even if the password is encrypted.   an expiring digest key seems much more along the lines of standard web application design, and I hope that this scheme already exists in some expresso application.  digest keys are relatively easy to implement.  (tomcat uses a digest key as the session id, right?)

with regard to a scheme for ascending numbers in a cookie, it is not clear how this is workable and yet improves security.  a client may request 2 pages simultaneously from 2 browser windows (same browser app), and a given web page may consist of many pieces (e.g. images), with each piece generating an asynchronous request.  given that web pages are inherently asynchronous, how could a (serialized) incrementing key be maintained in this asynchronous environment?  and if a "block" of numbers is approved, how is this an improvement in security, since this "block" would be an open-source vulnerability?  (an incrementing key also implies a database write with each and every query.)

in summary, it seems to me that cookie authentication falls in the low-stakes security arena, and may not be worthy of the effort to concoct a sophisticated incrementing-key algorithm.  however, the expresso security story would be significantly improved if the cookie did not to have a password in it, encrypted or not.  a digest key would suffice.

larry

At 09:06 AM 10/15/2002, Tino Dai wrote:
>Hi Everybody,
> 
>   I have been thinking about this login cookie that we have been
>tossing around (no pun intended), and I think that the ascending numbers
>scheme might work (stress on the might). My idea behind this would be
>with every packet that is send, the cookie would get updated with the
>next number. And if we could get blocks of continuous numbers, that 
>would represent a legal user that is logged in. But, that doesn't block
>hackers from stealing your cookie. Now, my idea along these lines was to
>have a separate cookie for each machine that you are logged in from. And
>each of thse cookies would have an ascending counter that is independent
>from one another, thereby making the gaps a non-issue. Also, we can look
>at a symmetric key, server-timestamped, encrypted cookie. What do you
>guys think about that?
>
>-Tino
>
>> 
>> But this is defeating the point of having a login cookie in the first 
>> place.  The point of it is to allow instant login over a significant period 
>> of time. (ex: 90 days).  If the user is a notebook user, they will 
>> DEFINITELY be switching locations time and time again.  So having the 
>> functionality of a login cookie becomes a moot point.
>> 
>> [To David H. now]
>> RE: counter.
>> I thought of that, but my problem is that I, for example, switch between 
>> browsers quite often, and thus the system would squeel, and cry 'replay 
>> attack', when all I did was switch my browser or switch my machine.  I DO 
>> think it's significantly simpler CPU-wise.  Thinking about it, I guess if I 
>> switch browsers, I would create a 'gap' in the numbering sequence, and I 
>> could record that 'gap' on the server's database.  If a cookie presents 
>> itself with that gap record, then we update it with the latest sequence, 
>> and remove the 'gap' entry from the internal records.  Could be a source of 
>> error, but what do you guys think?
>
>
>_______________________________________________
>Opensource mailing list
>Opensource at jcorporate.com
>http://mail.jcorporate.com/mailman/listinfo/opensource
>Archives: http://mail.jcorporate.com/pipermail/opensource/