I was reading the Wordpress Whitepaper v1.2 at BlogSecurity.net and read some useful tips to making Wordpress more secure. My question is could/would any of these recomendations make IPB more secure? I have also included what I know about already :D

For example:

Is this safe to have blank, just something like ibf_, ipb_ etc or would it be better as they suggest to have something more random i.e 95MkN8 to prevent database injection threats?[*]They also have the ability for generating secret keys at https://api.wordpress.org/secret-key/1.1/ which creates something like this for Wordpress. define('AUTH_KEY', 'l4Zyc=XP3D4C1b`#k~Zj1TYh,dT/C/:9+{wx,ZhVXI]8!O7VIXDjs]iPhpPx[zmp'); define('SECURE_AUTH_KEY', ')EU[Nf`FRl9mYvh4Xzc.h:2DI`Jv-v!5l27d=]Ks1K$f{}3z/|a:o-d2pedu.Dyq'); define('LOGGED_IN_KEY', 'Z/=ujR`e^1fuGnb[4} 4FP!ASkozQ~>(!~Xbd@4coz-Kp ,07%|O;_xSWw`p13&m'); define('NONCE_KEY', ' g-y+$I&WBL?nD4.;Xw<f:x|*36FDEn9<)D<6EFO~vE_BlN6Uta?F2Y_`(]dQD-L');

[*]They mention when creating the database user to only give GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP permissions. Is this the same for IPB?[*]With regards to the sql tbl prefix:

[*]Restricting access by requesting a password using .htpasswd and .htaccess[*]Restricting access to it by entering static IP addresses of those admins who have permission to it.

[*]Renaming the folder and changing the new name in the initdata.php file i.e [quote name='Axel Wers' date='11 July 2009 - 03:51 PM' timestamp='1247323885' post='1824402'] You are secured. To improve this, change CHMOD of your renamed admin directory to 501.

define( 'CP_DIRECTORY', 'XP3D4C1b' );

[*]CHMODing the directory to 501 as suggested:

What do you think of these ideas? Please give your feedback as I am sure it will benefit many IPB owners and administrators :D

$INFO['sql_tbl_prefix']   = '';

I think IPB has something like this from what I remember but wasn't too sure so thought I would mention it [*]Creating a very secure password for the Admin CP, FTP, MySQL etc goes without saying but how many people actually do? I generate a 16 alphanumeric password with special characters included.[*]Restrict access to the Admin CP by:

Oh yeah.
I am also interested about it.

Add:

6. Use https to for the authentications. (Both Forum and ACP)
This seems built-in in 3.0 already.
After login, use un-encrypted http for normal access.

7. When ever someone trying to access ACP. Make a email notification.

[quote name='Ballet' date='12 July 2009 - 06:51 AM' timestamp='1247395908' post='1824792']
Oh yeah.
I am also interested about it.

Add:

6. Use https to for the authentications. (Both Forum and ACP)
This seems built-in in 3.0 already.
After login, use un-encrypted http for normal access.

7. When ever someone trying to access ACP. Make a email notification.

#6 https is an option for forum login. If used for ACP, that too should be an ACP setting. Not all installs support SSL and for those that do, they may not necessarily have a certificate.

#7 Would just be plain annoying, especially if you are the one doing it and you do a few things, get busy with other stuff, sign back in, sign out and back in, test ACP with another account, etc. Perhaps as an option and to prevent annoyingness, have it report once per IP during a 24hour time period.

1) You *could* create your database user with limited permissions (I don't know the maximum required off hand)... however, if someone gets hold of your SQL username and password (or otherwise finds a way to execute arbitrary SQL commands), I think it's safe to say you're pretty screwed even with those permissions. Amongst what you list is DELETE and DROP - that's everything that's needed to destroy a database.
That one sounds just like a way to make people feel more secure.

2) That won't prevent injection threats. I believe the thinking is if someone has found an injection vulnerability, it will limit the damage they can do, but, as I said before, if someone has found a way to execute arbitrary SQL commands - it's kind of beyond the point of help. All they need to do is run "SHOW TABLES;" and they'll see a list of your tables, thus showing your prefix.

3) Not totally sure what those keys are for...

4) Yes, a secure password is always good :)

5) All those are good ideas, and there are features in IPB for doing them.

6) The option is in 3.0, although, for many people, it's probably not worth the expense ;)

7) I agree with Wolfie, that just seems annoying to me: "Hey, you just signed in to the ACP!"

Thanks Mark for repying and explaining that 1 and 2 aren't needed and providing you create really strong passwords (changing them often too) for the Admin CP, FTP and MySQL with restricting access to the Admin CP with what I mentioned in point 5, then it should be pretty much secure

[quote name='.Wolfie' date='12 July 2009 - 11:37 AM' timestamp='1247413069' post='1824884']
#7 Would just be plain annoying, especially if you are the one doing it and you do a few things, get busy with other stuff, sign back in, sign out and back in, test ACP with another account, etc. Perhaps as an option and to prevent annoyingness, have it report once per IP during a 24hour time period.

[quote name='Μark' date='12 July 2009 - 01:44 PM' timestamp='1247420648' post='1824954']
7) I agree with Wolfie, that just seems annoying to me: "Hey, you just signed in to the ACP!"

Sometimes security can be annoying, but there is acceptable annoying and just pure annoyance. Which is why I mentioned the idea of it being a report once every 24hrs per IP address (or perhaps once every 24hrs per IP address for every credential used would be better). That way if you're not using the ACP and then notice 2 or 3 members have signed into the ACP, all from the same IP, then you know there's an issue. But if someone is doing stuff in it, you won't get notified several times a day for that same login/IP combination.

[quote name='.Wolfie' date='13 July 2009 - 01:53 AM' timestamp='1247421232' post='1824964']
That way if you're not using the ACP and then notice 2 or 3 members have signed into the ACP, all from the same IP, then you know there's an issue.


Agreed!


About #2.
Would it be better only allow localhost access?
I.e. Bad guys have to gain remote access (e.g. ssh) to the server first, then do something bad to the database.

localhost acces won't benifit some people as some hosts don't actually allow SSH connections or even remote access.