Re: Cookie Persistence

Sorry, but a couple of additional comments:

Quoting Hamish:
"3. Even encrypted cookies are vulnerable to being stolen. There's  
nothing in an encrypted cookie that would stop a 3rd party from  
stealing it."

That's only true if you arbitrarily use the same key across all
cookies/clients.  Asymmetric encryption, which is what is done here isn't
compute intensive enough to require that.  The key used to encrypt the
cookies--even if it simply uses something like the original source IP and
port as seeds or components--can be unique to each client and maintained on
that basis and unless the 3rd party knows exactly what those are, stealing
the cookies won't be that useful.  Again, I realize that this does NOT work
for long-lived sessions cookies where the client might change IP address,
etc unless you have some massive lookup table based on client authentication
or something OR use client certificates in your application as the key.  The
point is--sure, nothing will stop it from being stolen, but there are things
that can prevent that stolen cookie from being used.  Again--will this stop
seriously targeted attackers?  NO, nothing will.  But it *will* prevent a
lot mischief.

Quoting Hamish:
"Yes. If only to prevent accidental leakage. But cowboys who place  
private data INTO a cookie should still be sacked. Sadly I don't think  
they ever will be. Unfortunatley the very nature of trying to prevent  
the leakage is likely to result in more problems... People will  
continue to put data in cookies because they got away with it last  
week and you protected them. What are they going to do when their code  
has to run WITHOUT an ADC?"


So--do people drive less safely because they have airbags and seatbelts in
their car?  Do you simply leave your house doors unlocked because you have
an alarm?  This is starting to sound like the old argument against
web-application firewalls--if the code was written right, then there
wouldn't be an issue; except that what we know to be a vulnerability today
wasn't yesterday when the code was written.  No one is saying that we
shouldn't fire/sack those people and there should be a STRONG enforcement of
ensuring that they never get away with it--but  that doesn't have any impact
on whether we should do everything we can to make sure that IF it happens,
we have a secondary means of mitigation.  Oh--and bite your tongue--running
an application without and ADC; blasphemy! :-)

Again--it all comes down to risk management.  Due diligence says that you
CANNOT ignore the potential that personal information may be stored in a
cookie--OR a cookie alone may provide direct access to that information with
little to no other authorization.  Due care says that you MUST do everything
reasonably within your power to prevent any risk identified through due
diligence.  If the cost of the impact of the threat is greater than the cost
to mitigate, you are compelled to mitigate. IF you didn't do something as
simple as encrypt your cookies and you had the capability to do so very
easily--and an incident occurs because of this--YOU are at fault.  You knew
the risk, you had an easy mitigation technique, you didn't use it.  That's
security 101. 

Quoting Hamish:
"(Actually I'm probably maligning cowboys in the paragraph above.  
Perhaps we could call them politicians instead?)"

It's probably OK--most *real* cowboys probably aren't technology gurus so
they have little chance of seeing this; but, point taken. :-)

KJ (Ken) Salchow, Jr. | Manager, Technical Marketing D 651.423.1133 M
612.868.12588 P 206.272.5555 F 206.272.5555 www.f5.com

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki