So you've finished that shiny new website and you want make sure that you and your buddies are in control.  Besides the obvious things such as SSL and logging all access, there are a fewest practices for authentication/access that developers recommend.  Here are some of the recommendations:

• Require separate login pages for users and admin using the same DB table.  This will prevent XSRF and session-stealing, plus the attacker won't be able to access to admin areas) [Thief Master]

• Use complex passwords for admin accounts.  For example, "uvula{:&:>iuJ", not "12345".  Of course, you have to remember it. :) [Developer Art]

• Introduce an artificial pause between each admin password attempt to prevent brute force attacks.  [Lo'oris]

• Blocking users IP after a number of failed admin login attempts or requiring a CAPTCHA after a failed login (but not the first one, because that's really annoying) will also stop brute force attacks. [Thief Master]

• If the admin section is in a separate subdirectory, you should consider also adding webserver native authentication to that area (e.g. via .htaccess in Apache).  Then an attacker would need both the subdirectory password and the user password. [Thief Master]

• Consider Second level authentication such as client certificates (e.g. x509 certs), smart cards, cardspace, etc. [JoeGeeky]

• Restrict access to the admin area.  Only allow clients from trusted IPs/Domains. [JoeGeeky]

• Lock down IPrincipal & Principal-based authorization and make rights immutable and non-enumerable.  Also make sure that all authorization assessments are based on the Principal. [JoeGeeky]

• Set up an email notification system that alerts admins when any rights are upgraded.  This will help you catch an attacker that elevates his/her rights. [JoeGeeky]

• Consider fine-grained rights for admins.  Typical Role-Based Security (RBS) approaches are not as safe because some roles will end up with more rights that they need.  You should distribute rights based on the exact actions that a admin performs.  This could cause a lot of overhead with more diverse admin-types, but it is safer because rights are issued more sparingly. [JoeGeeky]

• Restrict the creation of further admins and carefully control what admins can do to other admins.  It's best to have a locked-down 'super-admin' client. [JoeGeeky]

• Consider Client Side SSL Certificates or RSA type keyfobs (electronic tokens) for added security. [Daniel Papasian]

• If you're using using cookies for authentication, use separate cookies for admin and normal pages.  One way is to put the admin section on a different domain. [Daniel Papasian]

• One possibility, if it's practical, is to put the admin site on a private subnet instead of the internet. [John Hartsock]

• Re-issue auth/session tickets when moving between admin and normal usage contexts of the website. [Richard JP Le Guen]

• Require equally strong mechanisms (using the above techniques) for basic users so that admins aren't the only ones with highly-secure accounts. [Lo'oris]

These tips were gathered in a question by UpTheCreek from StackOverflow.