There are a couple of things going on here. First, when a cookie itself has
the "Secure" flag set on it, all that does is provides an instruction to the
browser when it receives the cookie to only send that cookie back to the
server if the request is to an SSL protected site. It doesn't say anything
about the contents of the cookie itself. Basically, this just ensures that
a third party can't sniff your wire traffic and steal the cookie because SSL
is encrypting the channel itself.
For the cookie data to be encrypted, you need to use one of the protection
level flags. I'd suggest cranking it all the way up to "All". This
basically prevents the user from being able to interpret the cookie data or
change it. What that does is prevents a valid user from doing something
like changing the cookie data to impersonate a different user. You don't
want them to be able to do that either.
In terms of site partitioning, I'm sure there must be a good article on
doing that somewhere. I haven't done it personally, so I'm probably not the
best guy to ask about that. The sites I build are SSL-only, so I haven't
had to deal with having a mix.

I'm sure if you look around, you'll find
some good resources though.
Best of luck!
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Cory J. Laidlaw, Beyond01.com"
< > wrote in message
news:1897DDF2-3B9A-4C7B-953C-...
> Thanks for the link.
>
> So if I inteperet this article correctly, the setting in Web.Config
> declares
> that anytime an authentication COOKIE is sent, it is encrypted, correct?
>
> Does this force the entire page to be SSL Encrypted since it's in
> Web.Config, that would make the entire web encrypted, correct?
>
> I get why constantly encrypting the cookie is important because you don't
> want it exploited if someone captures it with a malicious script or
> something.
>
> You mentioned being able to partition the site into secured and unsecured
> pages. maybe this is truly what I need to do. Is there an example of how
> to
> do this? Is it just creating a new folder in the site and somehow marking
> that folder that it always requires SSL and then putting allo f the
> sensitive
> pages in the encrypted folder while keeping the public folders in the
> 'main'
> web?
>
> Thanks for your help
>
> "Joe Kaplan" wrote:
>
>> Setting requireSSL to True in the web.config for the forms authentication
>> section will take care of the Secure flag. I'd check out the additional
>> MSDN docs and articles on Forms auth to get more details. Here is one
>> starting place:
>>
>> http://msdn2.microsoft.com/en-us/library/1d3t3c61.aspx
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "Cory J. Laidlaw, Beyond01.com"
>> < > wrote in message
>> news:83DD9E6C-1081-42C9-A151-...
>> > hey Joe,
>> >
>> > Thanks for the advice. Do you know where I might see an example of how
>> > to
>> > set this tag?
>> >
>> > Thanks!
>> >
>> > Cory
>> >
>> > "Joe Kaplan" wrote:
>> >
>> >> That may be ok too, as long as EVERY request to the server that needs
>> >> to
>> >> be
>> >> secure goes though SSL. If you just secure the login page, that
>> >> likely
>> >> isn't enough. If you see a site doing that, I would not use it. I
>> >> especially would not give them your credit card. 
>> >>
>> >> You can partition your site into secure and unsecure areas. You can
>> >> also
>> >> set flags on your forms auth cookie to tell the browser to only send
>> >> it
>> >> on
>> >> an SSL connection (called the "Secure" flag). That is an important
>> >> detail
>> >> to remember. I'd also set the HttpOnly flag on the cookie while you
>> >> are
>> >> at
>> >> it, as that helps prevent against a variety of cross site scripting
>> >> attacks.
>> >>
>> >> Joe K.
>> >>
>> >> --
>> >> Joe Kaplan-MS MVP Directory Services Programming
>> >> Co-author of "The .NET Developer's Guide to Directory Services
>> >> Programming"
>> >> http://www.directoryprogramming.net
>> >> --
>> >> "Cory J. Laidlaw, Beyond01.com"
>> >> < > wrote in message
>> >> news:461D1794-3DD5-4122-8DD5-...
>> >> > Joe,
>> >> >
>> >> > thanks for responding. I see your point.
>> >> >
>> >> > I just notice that several websites only employ SSL at certain
>> >> > periods,
>> >> > say
>> >> > when providing credit card information. Once completed, they turn
>> >> > SSL
>> >> > off
>> >> > again.
>> >> >
>> >> > Cory
>> >> >
>> >> > "Joe Kaplan" wrote:
>> >> >
>> >> >> Why would you put only the login page under SSL? What makes you
>> >> >> think
>> >> >> that
>> >> >> provides any security? Sure, you can encrypt the connection when
>> >> >> the
>> >> >> user
>> >> >> is providing their plaintext password, but if someone snoops on a
>> >> >> different
>> >> >> request that isn't encrypted and steals the user's cookie (just as
>> >> >> easy
>> >> >> as
>> >> >> stealing the pwd from the form post), they own the user just the
>> >> >> same.
>> >> >> It
>> >> >> begs the question as to why bothering with SSL at all.
>> >> >>
>> >> >> Joe K.
>> >> >>
>> >> >> --
>> >> >> Joe Kaplan-MS MVP Directory Services Programming
>> >> >> Co-author of "The .NET Developer's Guide to Directory Services
>> >> >> Programming"
>> >> >> http://www.directoryprogramming.net
>> >> >> --
>> >> >> "Cory J. Laidlaw, Beyond01.com"
>> >> >> < > wrote in
>> >> >> message
>> >> >> news
2CD56D2-634F-4BAF-BB82-...
>> >> >> > Hi there,
>> >> >> >
>> >> >> > I need to setup a web site that starts with a public home page.
>> >> >> >
>> >> >> > I would then like to have a link to a login page so I can
>> >> >> > authenticate
>> >> >> > them
>> >> >> > against a database.
>> >> >> >
>> >> >> > When I launch my project, it starts under HTTP, which is great.
>> >> >> > How
>> >> >> > can
>> >> >> > I
>> >> >> > make sure the Login page is under HTTPS?
>> >> >> >
>> >> >> > Thanks for any help you can provide!
>> >> >> >
>> >> >> > Cory
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>