Forms authentication vs session variable

[Bjorn Sagbakken]

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

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

RE: Forms authentication vs session variable

If you are using forms authentication, you would normally attach the user
object to the forms authentication ticket in Application_Aut henticateReques t
(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
>
>
>

[Bjorn Sagbakken]

Re: Forms authentication vs session variable

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@yaho o.NoSpamMaam.co mwrote in message
news:1C1F8232-3E3C-417C-8FB2-42835BA4D7F0@mi crosoft.com...

If you are using forms authentication, you would normally attach the user
object to the forms authentication ticket in
Application_Aut henticateReques t
(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
>>
>>
>>

[Eliyahu Goldin]

Re: Forms authentication vs session variable

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@online.nowr ote in message
news:WKadnXoBYt myVp3V4p2dnAA@t elenor.com...

>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@yaho o.NoSpamMaam.co mwrote in
message news:1C1F8232-3E3C-417C-8FB2-42835BA4D7F0@mi crosoft.com...

>If you are using forms authentication, you would normally attach the user
>object to the forms authentication ticket in
>Application_Au thenticateReque st
>(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
>>authenticatio n), 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
>>>
>>>
>>>

>
>

[Bjorn Sagbakken]

Re: Forms authentication vs session variable

Thanks.

Bjorn
"Eliyahu Goldin" <REMOVEALLCAPIT ALSeEgGoldDinN@ mMvVpPsS.orgwro te in
message news:u8dojmUnIH A.3780@TK2MSFTN GP06.phx.gbl...

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@online.nowr ote in message
news:WKadnXoBYt myVp3V4p2dnAA@t elenor.com...

>>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
>>authenticatio n? 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@yaho o.NoSpamMaam.co mwrote in
>message news:1C1F8232-3E3C-417C-8FB2-42835BA4D7F0@mi crosoft.com...

>>If you are using forms authentication, you would normally attach the
>>user
>>object to the forms authentication ticket in
>>Application_A uthenticateRequ est
>>(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
>>>authenticati on), 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
>>>>
>>>>
>>>>

>>
>>

>
>