确保网站管理部分安全的最佳做法是什么？

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.