Re: Forms authentication vs session variable

Thanks.

Bjorn
"Eliyahu Goldin" <REMOVEALLCAPITALSeEgGoldDinN@xxxxxxxxxxxx> wrote in
message news:u8dojmUnIHA.3780@xxxxxxxxxxxxxxxxxxxxxxx
Whether you need to change your current application depends on whether you
are happy with the current level of protection. Consider various security
threats and see how relevant are they for you.

There is a known security vulnerability called "Session Hijacking", other
threats, and there are standard ways of protection. Look here for an
example:
How To: Protect Forms Authentication in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998310.aspx

With forms authentication being the standard approach, you can easier find
advices on making it more secure.

ASP.NET membership provider helps you in managing your users and roles.
You will need to take your own care after UI authorization, but at least
you can delegate user and role maintenance to ASP.NET.

--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net


"Bjorn Sagbakken" <bjo-sag@xxxxxxxxx> wrote in message
news:WKadnXoBYtmyVp3V4p2dnAA@xxxxxxxxxxxxxx
I know how forms authentication works, at least basically. But since I
already have a running application using the session approach as I
described, my question is : Is that less safe than using forms
authentication? In case yes, I wonder why?
(--> meaning: should I modify the running application to raise the level
of security?)

In the next application I will use forms authentication, but I am a but
dubious on using the built-in feature for roles. All the data for the
roles will be stored in a SQL database, and the authorization levels will
mostly not differ user access to specific webpages, but much more
detailed, like enabling buttons and adding menu-selection. So I was
thinking of storing these authorization levels in session. But, of
course, if there is a dynamical way to use the built-in role feature
without hardcoding this into the web.config file, I will certainly
consider this.

Bjorn

"Peter Bromberg [C# MVP]" <pbromberg@xxxxxxxxxxxxxxxxxxxx> wrote in
message news:1C1F8232-3E3C-417C-8FB2-42835BA4D7F0@xxxxxxxxxxxxxxxx
If you are using forms authentication, you would normally attach the
user
object to the forms authentication ticket in
Application_AuthenticateRequest
(which fires for every page request). This then becomes available on any
page
in the User property; there is no need to store it in Session. You can
find
plenty of good sample code on how to do this including adding the user
Roles
to the ticket.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short Urls & more: http://ittyurl.net


"Bjorn Sagbakken" wrote:

In a web-application with login creds (user, pwd), these are checked
against
a user table on a SQL server. On a positive validation I have saved the
userID, name, custno and role-settings in a userobject (custom build
class)
and added this to the session using as session variable like
session["User"]

For all other pages I have added a small test in the page_load event,
basically testing if the session["User"] != null, but also checking if
the
User-object contains a UserID != ""
Only if these tests are passed, the user gets the page reguested,
otherwise
he is redirected to the login page.

Well, all this works well, and I cannot see any security break here.
The
only information that passes between the client and the server is the
sessionID, and this is supposed to be secure.

Still, I have been reading about using forms authentication (Cookie
authentication), and this is also easy implemented. The test in each
page is
somewhat similar. But my question is: Is this actually more secure, or
is it
just another way to do it?


Bjorn









.