By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,078 Members | 1,733 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,078 IT Pros & Developers. It's quick & easy.

Forms authentication vs session variable

P: n/a
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
Jun 27 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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
Jun 27 '08 #2

P: n/a
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]" <pb*******@yahoo.NoSpamMaam.comwrote in message
news:1C**********************************@microsof t.com...
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

Jun 27 '08 #3

P: n/a
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" <bj*****@online.nowrote in message
news:WK*********************@telenor.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]" <pb*******@yahoo.NoSpamMaam.comwrote in
message news:1C**********************************@microsof t.com...
>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


Jun 27 '08 #4

P: n/a
Thanks.

Bjorn
"Eliyahu Goldin" <RE**************************@mMvVpPsS.orgwrote in
message news:u8**************@TK2MSFTNGP06.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" <bj*****@online.nowrote in message
news:WK*********************@telenor.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]" <pb*******@yahoo.NoSpamMaam.comwrote in
message news:1C**********************************@microsof t.com...
>>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



Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.