On the subject of Authentication
## Authentication is the basis of AAA ## AAA (Authentication, Authorisation, Auditing) only becomes useful if you can correctly determine who is at the front door, so everything starts with Authentication.
It's also where everything can go wrong: you really don't want to make it easy for a user to gain access to your name|password list, nor make it easy to bypass the check and get in, nor make it easy for a user to gain the ability to change someone else's authentication data.
## Use a SSO Service ## The first step to securing your user|password data is …do not save it. Seriously.
Compared to a motivated attacker, I can guarantee you that you suck at the business of security. Most devs know little to nothing about SSL, Certificates, CA, XSS, SQL Injection, Dictionary attacks, man in the middle, encryption, signatures, etc. And nor should they (actually, they should, but only enough to know to integrate with a dedicated SSO service.
##
SOC
Apply IT:AD:Patterns:SOC.
In other words, your app should not save authenticate your users, but send them off to a central secondary website that deals in authentication exclusively. And all it does is concentrate on protecting that data.
Think about investigating WIF,OAuth, or any of a myriad of other options than saving the data yourself.
The reasons are obvious: most companies can't afford the negative press of being hacked, and all their user's usernames and passwords divulged (the same goes for purchasing services btw). And the best way of not getting robbed is having nothing to steal. I repeat: do not Authenticate your users yourself.
Multiple Services
If you are going to mess around providing Authentication Services to your users, do not provide the functionality in a one size fits all.
A classic example of how not to design an Authentication Services is the ASP.NET MembershipProvider, that offers Authentication (logon/logoff) and everything else (authentication management, management of other users, etc.)
The smaller the area/options made available to end users, the less that you are forced to guard.
For example, the Login page should only need to Authenticate|DeAuthenticate.
Hence use something as lightweight as XAct.Security.IAuthenticationService.
If they need to update their profile/password, they would be navigating to another page, where they would gain access to XAct.Security.IAuthenticationSelfManagementService which gives them rights to change settings for themselves only. Finally, an Admin could use a different page, gaining rights to change settings for any user XAct.Security.IAuthenticationManagementService.
The idea is to give as much access/temptation as they could possibly ever need to use. If you used XAct.Security.IAuthenticationManagementService everywhere, you have in turn have to check/guard/log access to every method, everywhere, and the whole experience would turn into some kind of paranoid 'Twisters' game as you tried to predict correctly, and worry about every eventual potential break-in.