Re: SSL
From: Peter O'Reilly (Peter_OReilly_at_timeinc.com!N!O!.S!P!AM!)
Date: 04/28/04
- Next message: Doug: "RE: Accessing local .NET Web server very slow over 802.11b"
- Previous message: Mark: "ToolTip in a bound datagrid"
- In reply to: Mark: "Re: SSL"
- Next in thread: Steve Drake: "Re: Ram based Cookies"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 28 Apr 2004 14:02:40 -0400
"Mark" <field027@idonotlikejunkmail.umn.edu> wrote in message
news:OO61CEULEHA.2260@TK2MSFTNGP09.phx.gbl...
> Ah, good point. Let's assume I'm using SSL. What would it take for an
> authenticated user sitting at their client browser to modify their clear
> text ram based cookie values?
>
Your original message mentioned worries of a hacker. Your example above
notes
an authenticated user. The way I see it, how the hacker managed to get past
authentication is the greater risk
and concern.
In other words, if the person authenticated is really the person intended to
use the application, I do not see how any of what is contained in their
cookie would be alarming as they are undoubtedly aware of their own social
security number, credit card number, application settings selected or
inputted, etc.
Encrypted or not, keep in mind though that the user may see what cookie is
being set, even if it's a session (memory resident) cookie, using such
browsers as Mozilla and having such cookie alert setting turned on.
If such security is really paramount, I would create a cookie containing an
encrypted id that points to the user's session information contained on the
server such as a database. This plus implementing SSL is about as stealth
as one can imagine.
-- Peter O'Reilly
- Next message: Doug: "RE: Accessing local .NET Web server very slow over 802.11b"
- Previous message: Mark: "ToolTip in a bound datagrid"
- In reply to: Mark: "Re: SSL"
- Next in thread: Steve Drake: "Re: Ram based Cookies"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|