The TSA is a funny thing. They make us go through all these hoops and ladders to make it look like we’re safer. They check us for weapons, they check us for bombs in our shoes, and essentially they check for everything they know about. And we call it ‘Security Theater’ because it actually doesn’t make us one inch safer.(If you’re really interested, go read Bruce Schenier‘s books. The security methods in place pre-9/11 are the ones that have caught the bad guys. None of the new stuff has.)
At work, I have a product from a vendor that has pretty insecure passwords. I can’t make them expire, I can’t make them require special characters. In fact, you can pick a blank password if you want. There’s no security and most people use the same password (123456) because of it. It was up to me to invent something more secure, and I sat and studied the login form for the app. This was a locked down product, so hooks and actions, like we use in web apps, were unknown. But there was a hidden option, down in the bowels of an ini file, that was for ‘advanced username options.’
Unlocking that option gave me rules for usernames, just like you’d think. But how is that going to make things safer? We already used login ids of our initials plus a number, so if I could leverage that somehow, maybe I could do something. My idea was that if the login name was always pre-filled, and uneditable, with the same ID you logged into the computer with, then in order to ‘hack’ into someone’s account, they would either need their LDAP password, or the person would leave their PC unlocked. I thought it was genius, and after some fiddling around, found how to extend the settings to allow that.
Months later, the Auditors come around and say it’s not secure enough. We need to change the passwords more often. Even though the desktop password is the most secure of all passwords we use, and even though leaving your PC unlocked is a fireable offense, they said that since someone could gain access to your PC, the bad password was a problem. I remarked that they had a lot more to worry about in that case, and pointed out the vendor didn’t have a fix. They’re still arguing that one.
The problem is the auditors want to be able to feel safer. They know and understand LDAP security, ergo all things must comply. It is a benchmark of safety which, in many cases, isn’t going to make things safer. If you got my LDAP password, you now have access to everything I log into at work. That isn’t safe at all, is it? It’s a single point of failure.
Recently, someone asked why WordPress doesn’t let you move the wp-admin folder around, and that doing so would be safer. Actually they accused WordPress of being egotistic for not letting you move the folder, and for putting meta info in the source code. But let’s not get into where they’re wrong on that end. Why doesn’t WordPress let you move wp-admin? Certainly they could put the effort into decoupling the various places where it’s hard coded, put in a define you could override, just like we do for wp-content. Then you could move it where ever and you’d be happy. I cannot speak for the developers, but looking at the code (not insurmountable, just annoying), I see it as security theater.
Moving the wp-admin folder simply cannot make your site safer. It just can’t. Look at it logically, you still have to be able to get the folder, ergo people will still be able to figure it out. The rule of the web has always been ‘If it’s on the web, people will take it.’ Normally this applies to pictures and text, but when we extrapolate it to include source code, like for open source code, which is there for the taking, we reach a point where anyone can look at WordPress’s code and determine how to quickly figure out where the admin folder has been moved to. We have now put in extra work for a very teeny tiny benefit, that can easily be circumvented.
But isn’t that benefit worth it? Not when you look at the costs. Computers do what we tell them to, every time, every day, repeatably. When we go in and complicate our code, we introduce more human errors. The more possibility for errors, the more likelihood that we’ve missed something. So by adding in a way to move wp-admin, we run the risk of screwing it up and making things less secure. Would you rather have the brains staring down WordPress and trying to make things actually more secure, like by preventing XSS vulnerabilities, or locking down nonces and cookies, or would you like them to make you feel better?
Furthermore, there are the themes and plugins to consider. Now we have to update all our themes and plugins that are
doing_it_wrong() in the first place, and get them to join the new world order of right. Yes, they should have done things right in the first place, but some don’t because the old way still works. What happens when they don’t update? We’ll have to leave some deprecated code in there so the old wp-admin still works and … oh. Well that didn’t do you any good, now, did it?(NB. I’m certain there is a way to do this. I just don’t care enough to verify it, as you’ll see in a moment.)
This has everything to do with the fact that open source software is open source, and ‘hiding’ anything means it’s always going to be easily reverse un-hidden. Moving wp-admin is called ‘Security by Obscurity’ and it’s a waste of time. It’s just not effectual in the long run, it doesn’t protect anything, and the only time someone knowing my WP version or where it was installed would worry me is if I didn’t upgrade and there was a known hack on the older versions. Even then, Hackers will just try the same attack even if I’m protected (which I know from the TimThumb debacle, where my server was scanned for the file exploit – I don’t use timthumb, but they scanned me all the same).
When you make me draw the line between where I’d want ‘my’ developers spending time, and the options are ‘feel good security’ and ‘make the damn product actually more secure’ … I think you know where I stand.
What about you? What aspects of ‘security’ do you feel are just window dressing?