Hi, and thanks for your feedback
I wish you would do it on the blogs comments, since there are a lot of similar good comments there, but okay, this works too.About fingerprinting:
Sure, if a potential attacker is at a site wanting to find out if it's Joomla or not, it's probably not possible to prevent that. The points outlined though, are the ones that keep you under the script kiddies' radar, those who prevent your site from appearing in simple Google searches for instance.
Among the 58 points mentioned, I can at first glance see the following ones touching on the matter of fingeprinting:
#5: Don't install sample content. This is a bad idea to begin with, as it has no place on a live site anyways.
#6: Remove the generator tag.
#7: Replace default Joomla meta information with your own data. The default metadata has no place on a live site either.
#14: Use SEF (user friendly) urls. Which is a good idea anyways.
#17: Make fingerprinting your site harder. The title here should really be "make fingerprinting your server harder", so I don't know if it should really count.
#41: Developers: Don't show off the names and version number in your extension.
So I can find 6(?) out of 58 points being partially about preventing easy Google-fingerprinting, so I'd object to the list being "mostly" about this topic.
These measures are not about sticking your head into the sand and hoping for the best. It is mostly about dodging your average script kiddie who's just searching around, or having spiders search around, for easy targets in the form of fingerprinting sites which have known security holes.
Consider the official security checklist
and you'll see that they also recommend you consider removing "welcome to the front page" to reduce search engine attacks.
If you ask me, this list would be 5 or 6 points shorter if Joomla just had a decent automatic upgrading system, like Wordpress Concerning the queries for changing the user id
; I think that part is correct. Which table is missing? If you want to be really hardcore about it, you could update any matching userid in the sessions table too of course. Then again, if you have actually used
your admin user to create content and stuff like that, you would break any links to the created_by column in the articles table of course. The same goes for any component which uses userid as a foreign key of course.
Btw, the part you mention about ?tp= ?template= etc, is all covered in the improved .htaccess-file (by @nikosdion) that I link to in #13: Enhance the .htaccess-file.And one more thing:
Do you have anything you'd like me to add to the list? I'd like it to be as good a resource as possible for all that needs it, and I am far from all-knowing, so any input is appreciated.