Random comment: Writing this may make you an instant "authority" on WP security. Be careful about that... You can easily get tied up in this stuff forever (although maybe that's what you want). Also, people may start to blame you if they tried to listen and then things go wrong. Do what you want with these comments... I don't know that you want them all in the article, so take what you like. Sometimes I get a little too paranoid.  :)

The "Server vulnerabilities" part could use a little more info. I think you should talk about limiting access to things, not just through wordpress, but directly on the server. If possible, don't put stuff on the server that it doesn't need... Turn off services, daemons, etc, and remove programs that aren't needed. If it's not there, it can't be used against you. What you DO want, make sure it's locked down... If it's not supposed to be runnable from the web, make sure that no accounts that are controllable from web-driven accounts (like wp-admin?) have access to anything they shouldn't. If you use FTP or something on the machine, consider using secure FTP, limiting the places it can write files, and/or using a limited account for it, if possible.

"Network vulnerabilities", I would avoid talking about the ends of the network, because it's the entire network that you have to trust. If your wireless access is super-encrypted and authenticated, but then it gets sent in plaintext once it hits the internet, you're still leaving yourself open. Other than that, I think it's OK (although I didn't read the linked articles).

"Passwords": Sounds reasonable... You could add a tarpitting system in there (it responds slower the more passwords they get incorrect (must be per-connect, to prevent a DoS)), but that's not a solution, just a hack, really. All you really need to do is avoid guessable/attackable passwords (which includes short passwords, guessable ones, or dictionary-able ones). Brute-forcing a password over HTTP should be pretty slow, and hopefully you'd notice them (there should be an alarm somewhere that says "there have been over X bad login attempts in the last hour" or something... If there's not, consider writing one!).

As an aside, I saw an interesting presentation recently that talked about this (among other things). I don't think it'll apply as much for WP logins, since they all probably require string passwords, but consider this: On a machine, eventually all passwords process down into a hash value. No matter how short or long it is, it'll resolve to, say, a 32 bit value. This is what people are actually trying to break. Classically, people have a dictionary of pre-generated hashes they try that contain all the short password combinations, so they're still pretty insecure, but after you reach a certain length, it doesn't matter... They're not going to able to brute-force it (unless it's a single word or something else easily dictionary-able). A 1000 character password isn't really any more secure than a 50 char password, because they both hash down to the same length, and neither is really vulnerable to a dictionary attack. I don't think I'd include this in the article (especially because I doubt you can use password hashes in the WP system), but it was sort of eye-opening to me when I heard it.

"File permissions": This sections seems very sound advice.

"Database security": Also, choose good, different passwords for the databases than WP, if possible. If possible, restrict the security here much like in "File permissions" - only the account(s) that need to should be able to write to the different tables, ESPECIALLY if there is configuration/password/user account stuff in a table.

Also, this might be a good time to note SQL vulnerabilities. NEVER take any string from the internet and directly put it in a SQL statement. You must strictly validate all data (don't put in exclusionary filters. You should know what is allowed in your database, so you should know the format for it. It is better to accidentally exclude valid content than to ever allow bad content). It is easy to allow bad things in a SQL statement, especially because of the '--' inline comment operator. If you don't get what I mean here (either about filtering or the SQL vulns), let me know.

"Securing wp-admin": Personally, I think all such logins should be through HTTPS, and you shouldn't use cookies, but perhaps I'm a little too paranoid? I'm not a real expert on these aspects of security, though, so maybe I'm guilty of thinking it'll protect me more than it does. There're always possibilities that information will somehow leak out, and I'm just unaware.

"Code execution plugins": if a "Code execution plugin" truly executes code, I think it's too late... Does it have a buffer overflow or other type of vulnerability? Suddenly arbitrary evil code is running on your system and all bets are off. Hopefully the account the plugin uses is locked down and can't do damage. Basically, I'm saying that when you allow something to run on your machine, you're pretty much allowing it control over everything and anything that account has control over. Very scary. If you can run the plugin as a different, even more restricted user, that's not a bad idea.

"Security through obscurity": As you mention, obscurity is a bad primary strategy, but not bad in general. I think I've heard renaming the admin account is not that useful, but it'll probably stop a normal script kiddie. There are likely ways to list user accounts or something. You're better off just using a good password (although I suppose both can't hurt too much). If nothing else, it'll help prevent installation of stuff that wants admin access to the database, which should never be allowed, IMO.

"Data backups": You're even more paranoid here than I am.  :) I suppose you're talking about leaving backups on the server? They'd be MUCH better off with CDRs or something, if only because the backups are incase the machine dies too, not just for rebuilding from a security breach. I definitely recommend off-site/machine backups. If you leave it on the machine, make sure to lockdown access to it, too.

As for the other part, I agree... It's better to have continual, rolling snapshots, the more the better, perhaps with a fixed, permanent one from time to time. A single backup is better than nothing, but once you overwrite it, that's it... You can't go back.

You may want to put in a specific section about validating data... All data from the internet is untrusted. You should thoroughly validate it before trusting it (maybe WP does this? I wouldn't trust it, but hopefully it does). As mentioned below, be as restrictive as possible. Don't create exclusionary rules... Only accept something if it looks correct, don't deny it because it looks bad... There are plenty of different ways to represent the same things, and if you miss one in your exclusion list, you're screwed. Instead, only accept it if it looks good, and be as restrictive as you can.

For example, these locations are the same... what are the chances you'll remember to exclude all of them and that they are the only ways to do it (there should be another way if you're using NTFS, but I couldn't get it working)?: C:\file.txt file://c:\file.txt file:///c:\file.txt file:///c:/file.txt file:///c:/file.txt. C:\windows\..\file.txt \\?\i:\boot.ini \\127.0.0.1\c$\file.txt \\localhost\c$\file.txt

A really important point I think you could work in: When in doubt, restrict permissions. You can always go back and increase permissions later, temportarily inconvenienced. If someone gets in because the permissions were too loose, you could already have lost everything on that machine, maybe others.

Well, there you go... My 2 cents plus some.  :) I hope it's helpful.

Pat