What are best practices for securing the admin sec

问题:

I'd like to know what people consider best practice for securing the Admin sections of websites, specifically from an authentication/access point of view.

Of course there are obvious things, such as using SSL and logging all access, but I'm wondering just where above these basic steps people consider the bar to be set.

For example:

• Are you just relying on the same authentication mechanism that you use for normal users? If not, what?
• Are you running the Admin section in the same 'application domain'?
• What steps do you take to make the admin section undiscovered? (or do you reject the whole 'obscurity' thing)

---

So far, suggestions from answerers include:

• Introduce an artificial server-side pause into each admin password check to prevent brute force attacks [Developer Art]
• Use separate login pages for users and admin using the same DB table (to stop XSRF and session-stealing granting access to admin areas) [Thief Master]
• Consider also adding webserver native authentication to the admin area (e.g. via .htaccess) [Thief Master]
• Consider blocking users IP after a number of failed admin login attempts [Thief Master]
• Add captcha after failed admin login attempts [Thief Master]
• Provide equally strong mechanisms (using the above techniques) for users as well as admins (e.g. don't treat admins specially) [Lo'oris]
• Consider Second level authentication (e.g. client certificates, smart cards, cardspace, etc.) [JoeGeeky]
• Only allow access from trusted IPs/Domains, add check to basic HTTP pipeline (via e.g. HttpModules) if possible. [JoeGeeky]
• [ASP.NET] Lock down IPrincipal & Principal (make them immutable and non-enumerable) [JoeGeeky]
• Federate Rights Elevation - e.g. email other admins when any admin's rights are upgraded. [JoeGeeky]
• Consider fine-grained rights for admins - e.g. rather than roles based rights, define rights for indicidual actions per admin [JoeGeeky]
• Restrict creation of admins - e.g. Admins cannot change or create other admin accounts. Use a locked-down 'superadmin' client for this. [JoeGeeky]
• Consider Client Side SSL Certificates, or RSA type keyfobs (electronic tokens) [Daniel Papasian]
• If using cookies for Authentication, use separate cookies for admin and normal pages, by e.g. putting the admin section on a different domain. [Daniel Papasian]
• If practical, consider keeping the admin site on a private subnet, off the public internet. [John Hartsock]
• Reissue auth/session tickets when moving between admin/normal usage contexts of the website [Richard JP Le Guen]

回答1:

These are all good answers... I generally like to add a couple additional layers for my administrative sections. Although I've used a few variations on a theme, they generally include one of the following:

• Second level authentication: This could include client certificates (Ex. x509 certs), smart cards, cardspace, etc...
• Domain/IP restrictions: In this case, only clients coming from trusted/verifiable domains; such as internal subnets; are allowed into the admin area. Remote admins often go through trusted VPN entrypoints so their session would be verifiable and is often protected with RSA keys as well. If you're using ASP.NET you can easily perform these checks in the HTTP Pipeline via HTTP Modules which will prevent your application from ever receiving any requests if security checks are not satisfied.
• Locked down IPrincipal & Principal-based Authorization: Creating custom Principles is a common practice, although a common mistake is making them modifiable and/or rights enumerable. Although its not just an admin issue, it's more important since here is where users are likely to have elevated rights. Be sure they're immutable and not enumerable. Additionally, make sure all assessments for Authorization are made based on the Principal.
• Federate Rights Elevation: When any account receives a select number of rights, all the admins and the security officer are immediately notified via email. This makes sure that if an attacker elevates rights we know right away. These rights generally revolve around priviledged rights, rights to see privacy protected information, and/or financial information (e.g. credit cards).
• Issue rights sparingly, even to Admins: Finally, and this can be a bit more advanced for some shops. Authorization rights should be as discreet as possible and should surround real functional behaviours. Typical Role-Based Security (RBS) approaches tend to have a Group mentality. From a security perspective this is not the best pattern. Instead of 'Groups' like 'User Manager', try breaking it down further (Ex. Create User, Authorize User, Elevate/Revoke access rights, etc...). This can have a little more overhead in terms of administration, but this gives you the flexibility to only assign rights that are actually needed by the larger admin group. If access is compromised at least they may not get all rights. I like to wrap this in Code Access Security (CAS) permissions supported by .NET and Java, but that is beyond the scope of this answer. One more thing... in one app, admins cannot manage change other admin accounts, or make a users an admin. That can only be done via a locked down client which only a couple people can access.

回答2:

If the website requires a login for both regular activities and admins, e.g. a forum, I'd use separate logins which use the same user database. This ensures that XSRF and session-stealing won't allow the attacker to access administrative areas.

Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.

Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).

A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.

回答3:

• I reject obscurity
• Using two authentication systems instead of one is overkill
• The artificial pause between attempts should be done for users too
• Blocking IPs of failed attempts should be done for users too
• Strong passwords should be used by users too
• If you consider captchas ok, guess what, you could use them for users too

Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".