What are best practices for securing the admin section of a website? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 10 years ago.

Improve this question

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 s开发者_JAVA技巧ection 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]

---

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.

---

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.

---

• 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".

---

If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.

So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.

---

Have a good admin password.

Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Add a pause for each password check to prevent brute force attack.

---

Here are some other things to consider:

1. One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
2. If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
3. Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.

---

We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.

---

The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).

If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.

Naturally the editing stage should only be available on a local intranet and/or using a VPN.

This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.

Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.

---

It very much depends on what kind of data you want to protect (legal requirements and such).

• Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)

• Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.

---

I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.

---

Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.

Perhaps you could always put the administration section in a big directory, e.g.

http://domain.com/sub/sub/sub/sub/sub/index.php

But that's not really good hah.

Perhaps you could include a query string in the home page, like:

http://domain.com/index.php?display=true

When it does, the username and password field will appear.