cates that the cookie should not be permanently stored on the client machine. Its lifetime will be the duration of the user session by default. This can be altered if so desired.
Back to web.config to improve the security. The details are being stored unencrypted – we can encrypt them with the aforementioned HashPasswordForStoringInConfigFile of the FormsAuthentication class, achieved simply as follows: Private Function encode(ByVal cleartext As String) As String
encode = FormsAuthentication.HashPasswordForStoringInConfigFile(cleartext, "SHA1")
Return encode
End Function
This is the key function of the encode.aspx file provided with the code download, which accepts a text string (the original password – ‘password’ in this case) and outputs a SHA1 encoded version care of the above function.
Thus, our new improved configuration section of our root web.config file becomes: <credentials passwordFormat="SHA1">
<user name="chris" password="5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8" />
</credentials>
To summarize the involved files:
Root/web.config root web.config file
Root/webform1.aspx test page
Root/login_credentials.aspx login page
Root/encode.aspx form to SHA1 encode a password for <credentials>
Root/secure/web.config directives to override security for this sub-directory to deny anonymous access
Root/secure/webform1.aspx test page
Conclusions
We’ve looked at the new security features of ASP.Net focusing particularly on an application scenario where forms based authentication uses the credentials section of web.config, but presenting this in the context of wider security issues.
In summary you should consider forms based authentication when:
User names and passwords are stored somewhere other than Windows Accounts (it is possible to use forms authentication with Windows Accounts but in this case Integrated Windows authentication may well be the best choice).
You are deploying your application over the Internet and hence you need to support all browsers and client operating systems.
You want to provide your own user interface form as a logon page.
You should not consider forms based authentication when:
You are deploying an application on a corporate intranet and can take advantage of the more secure Integrated Windows authentication.
You are unable to perform programmatic access to verify the user name and password.
Further security considerations for forms based authentication:
If users are submitting passwords via the logon page, you can (should?) secure the channel using SSL to prevent passwords from being easily obtained by hackers.
If you are using cookies to maintain the identity of the user between requests, you should be aware of the potential security risk of a hacker "stealing" the user's cookie using a network-mo
Back to web.config to improve the security. The details are being stored unencrypted – we can encrypt them with the aforementioned HashPasswordForStoringInConfigFile of the FormsAuthentication class, achieved simply as follows: Private Function encode(ByVal cleartext As String) As String
encode = FormsAuthentication.HashPasswordForStoringInConfigFile(cleartext, "SHA1")
Return encode
End Function
This is the key function of the encode.aspx file provided with the code download, which accepts a text string (the original password – ‘password’ in this case) and outputs a SHA1 encoded version care of the above function.
Thus, our new improved configuration section of our root web.config file becomes: <credentials passwordFormat="SHA1">
<user name="chris" password="5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8" />
</credentials>
To summarize the involved files:
Root/web.config root web.config file
Root/webform1.aspx test page
Root/login_credentials.aspx login page
Root/encode.aspx form to SHA1 encode a password for <credentials>
Root/secure/web.config directives to override security for this sub-directory to deny anonymous access
Root/secure/webform1.aspx test page
Conclusions
We’ve looked at the new security features of ASP.Net focusing particularly on an application scenario where forms based authentication uses the credentials section of web.config, but presenting this in the context of wider security issues.
In summary you should consider forms based authentication when:
User names and passwords are stored somewhere other than Windows Accounts (it is possible to use forms authentication with Windows Accounts but in this case Integrated Windows authentication may well be the best choice).
You are deploying your application over the Internet and hence you need to support all browsers and client operating systems.
You want to provide your own user interface form as a logon page.
You should not consider forms based authentication when:
You are deploying an application on a corporate intranet and can take advantage of the more secure Integrated Windows authentication.
You are unable to perform programmatic access to verify the user name and password.
Further security considerations for forms based authentication:
If users are submitting passwords via the logon page, you can (should?) secure the channel using SSL to prevent passwords from being easily obtained by hackers.
If you are using cookies to maintain the identity of the user between requests, you should be aware of the potential security risk of a hacker "stealing" the user's cookie using a network-mo
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
