Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • Still Not Using Plugins for Security

    Still Not Using Plugins for Security

    Seven years, and my answer to 'do I need a security plugin' is the same.

    Nope.

    What is a Security Plugin?

    A security plugin is not a plugin like 'brute force protect' or 'limit login attempts.'

    A security plugin is like Better WP Security or WordFence or a hundred other plugins that promise to scan your site and let you know what's changed.

    This is not to say that first set of plugins aren't there to make you 'safer,' it's that those are single use, targeted plugins that address a single issue. Limiting login attempts prevents someone from trying the same attack over and over and over until they get in.

    By contrast, all-in-one security plugins try to do everything. They scan your code, your data, and your site. They look for all the possible attack vectors and they try to plugin them.

    What Makes That Secure?

    That's the question I ask people. If a plugin adds in 2-factor authentication, I ask them what it does for them? Password expirations, captchas, file compares etc. Those are all good things, individually, but are they applicable for all people? What, specifically, about those things makes you more secure or not?

    Now. Before you get all shirty with me, I am well aware of what all of those things are good for. With the exception of captchas (which are not accessibility friendly, please stop using them), all of those things make a lot of sense. You expire passwords and, one hopes, require strong passwords to make it harder to break in. But if you have a 2FA setup, do you need to require rotating passwords?

    It’s All About Thinking

    Security plugins stop people from thinking about what's going on.

    I've seen it time and again, people install a plugin that 'makes them safe,' follow the bare minimum of requirements, and then install whatever they want without thinking about it, leave registrations open, and oops, get hacked.

    This is not to say that security plugins don't prevent some of that from happening, but they're often an 'after the fact' solution. That is, usually a security plugin doesn't know to block X until X has been exploited. That's kind of the nature of the beast, though, and why WordPress and many other CMS developers don't release full details on security fixes until they've been out there for a while. They want to give people a chance to upgrade before saying "Hey, y'all who didn't are super vulnerable."

    It’s Also About Speed

    Security plugins also have a tendency to make your site slower. This usually comes up when people have turned on everything that comes with a security plugin. Which goes right back to my point about thinking. The user doesn't think, because they're not yet educated, about the impact of the code on their site.

    To put it simply, the more things you ask WordPress to do before it can load a page, the slower it will be to load a page.

    Pretty cut and dried, right?

    What’s My Answer?

    I don't call this the 'right' answer or even the best one. Not everyone has access to my resources after all, so it's not fair to say "Hire Mika to think for you!" But to me, the best answer is to use the resources you have intelligently.

    Firewalls, from a server side, are all but a requirement to me. If your web host doesn't have one, and most at least have ModSecurity, get a new web host. If you disabled it on your site because a random plugin doesn't work with it, delete the plugin and turn it back on. If you can't move to a new host, look into firewalls like Incapsula or Sucuri. Put something between users and data.

    Site Scanning is a great tool, but don't run it on WordPress. A great example of smart security scanning is VaultPress. It's a remote service that has a copy of all your files and it scans the copy, not your site, for issues. There are other services you can use that scan your site without affecting traffic. Again, web hosts often have tools for this.

    Be Aware of what's going on. Don't just let security be a black box. Make sure you know what kinds of attacks are common on your site. If you're hit by a DDoS, for example, where they're just hammering your site to take it down, a 2FA plugin will not help. If they're trying to log in all the time, a scanner is probably not what you need.

    Lock It Down. If you don't need it, don't use it. If you don't need it on, turn it off. Update regularly. Don't install everything under the sun. 

    Don’t Buy Into FUD

    This is a tricky balance. On the one hand, I want to say 'don't panic if your favourite security plugin of choice tells you everything doomed!' Remember, they're trying to sell you things. But on the other … don't think everything's fine and dandy.

    It's not a simple solution. You have to simultaneously be aware of problems and not overwhelmed by them. You have to learn how to care about which ones are important to you and which are not.

    In a word, you have to think.

    And there is no plugin on the planet that can think for you.

  • Thimking About Security

    Thimking About Security

    It's been a while since I last talked about security and WordPress plugins, so I thought it was a good time to do it again.

    I still don't use any. But we'll get to that in a minute.

    Don’t Be ‘Stupid’

    My mother is one of the few people I know who has almost completely conquered the will to be stupid.

    Miles Vorkosigan on his mother, Cordelia Naismith Vorkosigan
    Brothers in Arms by Lois McMaster Bujold

    Understanding what makes something secure or insecure is not as obvious as I wish it was. I often say that the trick to being secure is not being stupid. Of course that's easier said than done, and I know it.

    Still, my record holds true that the one time I was hacked, it was from my own stupidity. I knew it was wrong and foolish and I did it anyway. And my guiding principal of security remains a constant reminder "Don't be stupid."

    But what is stupid? Every time you leave your house, you lock your doors, right? You do the idiot walk, as my grandmother Taffy called it. Keys, wallet, phone? Is the gas off? Is the heat on? Are the windows closed? You check the normal things and then you lock the door and off you go.

    Of course, we all have been an hour into an 8 hour drive and panicked "Did I close the garage!?" And for some people, even the simple act of locking the door is an arduous journey of 10 or 30 or 55 checks. In order to say 'don't be stupid' we have take ourselves honestly and seriously, and remember that 'stupid' just means 'don't not think.'

    THIMK

    That was not a typo. Nor was the title of this post.

    While we all make fun of IBM and MAD Magazine, I recall reading "Welcome to the Monkey House" by Kurt Vonnegut, and Ma Kennedy had the sign over her desk. At the time, I was unaware of the MAD magazine spoof on the matter. THINK was a sign folks at IBM had, and THIMK was the spoof.

    When I read it in Vonnegut, and bear in mind I was young and naive, I found it far more compelling than the idea of telling someone to THINK. With the letter changed, it forced me to reassess my assumptions of what the meaning was. After all, telling someone to THINK means, well, think. But telling someone to THIMK is a different matter.

    Eating the Elephant

    You know that old joke? How do you eat an elephant? One bite at a time. Well. That's security.

    I've been a loud opponent of the TSA, the way it's implemented in the US currently. It makes us feel better by making us think (N) that something is being done. And, yes, the TSA has found problems. But their job is to look through a thousand small things and find the odd-one-out. They're looking for the weird.

    When we perform a security audit over anything, be it a plugin or a server, or a door, we look for what we know is likely wrong. When I review a plugin, I look for the common issues. I skim for them, or grep for them, because I know what I'm looking for, and my eyes are trained to find it.

    But then, once I see the major and common issues aren't there, I read the whole thing. I look at the plugin as a whole entity, and I think. What does the code mean? What is it's intent?

    Metaphysical Security

    Without the ability to spy into the soul of the developer and glean an understanding of their raisons d'être, we're left with monitoring actions and making best guesses. And we're going to be wrong from time to time.

    It's no secret that last year, the WordPress security world found a new villain in the despicable people who buy plugins and slip backdoors into them. I saw some complaints that this sort of vulnerability wouldn't exist in [insert your CMS here], except … it will. It can and it will.

    We are all vulnerable because we choose to trust. We trust the developer to have good intentions. We trust the reviewers to be good people and care more about the security and sanity of code than themselves (which is a whole different ball of fish). We trust the ongoing development not to be handed over to evil people.

    That last one is unavoidable. People trust me to review code and react in the 'best' way for the community. But what if someone found my asking price and bribed me? What if I let bad code like backdoors into the WordPress Plugin directory? It would probably get caught, eventually, but still. Even if we locked down plugins to specific users accounts and didn't let anyone but admins (like me and Otto) add users, we would still at the end of the day remain vulnerable to humanity.

    Security Is Ongoing

    The truth is this.

    We are always, every day, insecure and vulnerable.

    Having a website that is your 'life' or career or business or even just a passion-project is dangerous.

    You should treat your website with as much thought and security as you do your own home. Check the gas. Check the lights. Make sure the door is locked. Get a security system. Hire someone to review the site and the server. But take it seriously. 

    Your website is 'you' on the Internet. And it deserves as much care as locking your car and not parking it in a shady part of time.

    Summary?

    Pay attention to what you put on your website.

    Trust no one. Not even me.

  • The Purpose of a Case Study

    The Purpose of a Case Study

    Back in early December I gave a talk at WordCamp US about a website I built with Tracy. The talk was titled “Lesbians, Damn Lesbians, and Statistics.” You can watch it here:

    Of all the talks I’ve given, I feel it was the least WordPressy of them all. That is, while I did talk about WordPress and why we made choices that we did, and how they relate to the data design, it wasn’t very code heavy. It was, instead, a case study in how and why and what.

    What

    A case study talk is complicated because you have to address what the topic is beyond WordPress. When you start with WordPress, and you’re at a WordPress convention, you don’t have to lay the groundwork. You can jump in and talk about custom post types and taxonomies. At a WordCamp, everyone knows about WordPress, or at least enough to skip over the basics.

    On the other hand, your case study starts by explaining what the reason was that you built the site in the first place. What’s the purpose of the site and what’s the relation to WordPress. You start with the narrative of “This is my story.” And you have to do it fast because next is the why!

    Why

    Once you have explained what the site is about, you have to explain why WordPress. When you’re doing a normal talk about WordPress things, you skip right over this. Everyone knows why WordPress. Because WordPress! But many times we ask ourselves “Is WordPress the best tool for this job?” We ask “Is it the right tool?” So in a case study, you have to build up your case and explain why.

    This is hard, because you already jumped through those hoops to explain to yourself (and any business partners you’re working with) the rationale. Distilling all of that into a third of your talk, which means maybe ten minutes, is not easy. You summarize, you skip over things, and you still have to hit the main points or people won’t be able to make the connections for the next section.

    How

    Finally you have to explain how you did this. If people don’t understand what you did and why, the how becomes meaningless. This is because the brunt of your talk takes place here. This is the real WordPressy stuff, where you talk about how the what and why came together to be this thing. If people can understand the enormity of the data, they can conceptualize your logic.

    If you’ve built everything up before, people will understand “Oh, she couldn’t make death a taxonomy because the overlap would cause problems and become unwieldy.” They’ll follow you when you explain about faceting searches and moving data.

    Because

    The purpose of all this is to draw people in with a cohesive story that puts the code and the concept together. People remember songs because of the rhythm and pattern. They will remember your case study because of the story. We remember stories.

    The purpose of your case study is to tell a good story that people remember and that connects them to your topic and your code.

  • A Difference of Tone

    A Difference of Tone

    The other day I lamented on Twitter that one day someone would ask me “Why did you use X?” and not “Why DIDN’T you use Y?” in a tech talk.

    Think Different

    When you go into a talk, thinking you know everything about it and what it means, you close your mind. You start by ignoring the possibility that other people can have amazing thoughts and ideas too. You limit yourself. Your preconceived notions color how you think because you limit your experiences to that which you have personally.

    This is much the same as why a number of people seem to lack empathy until they’re personally impacted. That’s why you hear men say things like “I didn’t become a feminist until I had a daughter.” A number of people nod and understand his meaning is that it wasn’t personal. But a number of people also wonder what the hell is wrong with someone not to care about humans in general. Doesn’t that man have a mother? A grandmother?

    Once you allow yourself to accept the simple idea that someone else thinks a different way from you, you open your mind to a new world.

    Hear Different

    There’s a difference between listening and hearing. We all listen. But once you start thinking about what your reply will be, and not listening to what’s behind what the other person said, you limit yourself. I see a lot of people sit in talks and you can tell when they tune out because they’ve decided “I want to know X.” and that will be their question. Instead of writing it down to ask, they block out everything. They concentrate on their reply.

    Notice how I said ‘reply’ and not ‘question’?

    Yeah. There’s a reason.

    Ask Different

    When you go up to ask someone a question based on their talk, you’re not playing Jeopardy. The game isn’t “Phrase my answer like it was a question.” The point is to to ask something to understand a little better how someone else reached a conclusion. It’s the fundamental difference between “Why didn’t you use the Post 2 Posts plugin?” and “What did you use to connect the posts to each other and why?” The first one makes your preference known. It makes an assumption that obviously everyone would use Posts 2 Posts. The second one asks to get into the mind of the speaker, to learn the way another mind works. It assumes the other person is different from you.

    When you ask what someone used, and why, you get an insight into their process, which may help you reflect on your own. You may find new answers, and all you have to do is remove your own ego from the question.

    Learn Different

    The point of this is not to make a speaker’s life easier, but to make yours better. If you change just two small things in how you ask questions, you’ll find you can learn a whole lot more.

    1. Write down the question you want to ask
    2. Ask it without assuming you know the best answer

    You may be surprised how the tone of the ask changes everything.

  • Why I Do This

    Why I Do This

    Every once in a while someone makes a few veiled statements about how I must be on some kind of power trip, and that’s why I took control of the Plugin Review team as the rep. It’s not true.

    Why I am a Forum Moderator

    I was helping people and one of the mods asked if I’d join. I said yes. I’m currently still on the team, but I no longer am super active. I’m kind of on the cusp of the requirements for being a moderator, and if they removed me, I’d be okay with that.

    Why I was the Forum Representative

    We were just deciding who should be the very first reps for teams, and I was asked (along with someone else) if I’d be willing to try to help us figure out how we wanted to do this. I stepped down from that responsibility after a few years to lower my personal stress.

    Why I am a Plugin Reviewer

    I had been reporting a bunch of plugins doing bad things, as well as helping the gents figure out some crazy stuff. They abducted me and asked me to help. I did and bit by bit learned how to properly handle reviews. I keep doing reviews because I enjoy it.

    Why I am the Plugin Review Representative

    No one else wanted to do it and we needed someone to take responsibility and make some changes. Like with the guidelines. The directory etc. I still do it because it’s a needed job.

    But … WHY!?

    None of that answers the real question of why I do this at all though. If it’s not apparent, I literally fell into this job by accident and stuck around. I stick around because I enjoy what work I do and I learn from it. Learning about how people write code, the assumptions they make, teach me more about accidental security than all the time I worked at the Bank.

    But also I believe that any social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole. And to that end, I feel that the only right way to make plugin code reviews, or the forums, work is to get the community self-regulating.

    The problem with that theory is that not everyone is altruistic. If people within the community have a desire contrary to the rest of the community, it causes conflict and drama. Therefore, a true ‘socialist’ society requires people willing to be the ‘baddie’ and say things like “No, you can’t do that.” Basically, we need a parent who’s able to explain to the children why putting their hands on the stove is bad, and why throwing rocks at their friend was mean.

    I certainly don’t think I’m the only person who can do this. I just seem to be one of the few willing to do it in a consistent and continuous fashion. And that’s the reason I stick around. I’m trying to build a future where anyone can do technical code reviews for submitted plugins. Anyone. However that comes with a lot of responsibility for the community.

    While there are many people capable of doing a technical review, and many people competent at explaining bad code to developers, and many people wise enough to handle angry developers, that Venn Diagram has a very small crossover. And if you factor in people willing do to it, it gets smaller.

    For example. Everyone complains about the WordPress Plugin Guidelines being too strict and too vague. Last year I undertook the monumental effort of rewriting them for clarity and fairness. I asked people at multiple WordCamps to help. We sat and discussed what the guidelines meant and why they were worded in the way they were. Then I posted on the Make blog asking people to help.

    Of the few hundred people who complained, less than 20 had anything to say.

    From that, and other times I’ve reached out to the community and asked for help, and the results I’ve had, I feel that people aren’t willing to embrace all the aspects of the job. Yet. That’s why I’m slowly, carefully, working my way through the changes. I’m trying to lower the bar for them, to make them more amenable to join.

    It takes time.

    Yes, but that isn’t WHY!

    Oh right. Why do I do this?

    I review plugins because I legit enjoy seeing the crazy code people come up with. I help in the forums for the same reason. I like seeing what people do, and solving problems. I like writing the code to solve the problems too.

    I’m the plugin rep because it’s a dirty job, but someone has to do it, and I’m okay with being hated by people. I know I’m doing it to make code better and safer for users, to encourage developers to engage in ethical and kind business practices, and because I learn from them too.

    At the end of the day, I do this, all of this, because I can, because I enjoy it, and because I feel good when I help people.

    One day that may change. When it does, I’m sure I’ll walk away. That’s just not today.

  • Admins Are Humans Too

    Admins Are Humans Too

    This conversation happens often enough that I've ceased to be mind boggled by it. A developer will submit code, I review it, and I'll tell them to please sanitize the input. Instead of just using the functions, they'll come back and ask why? Invariably they'll point out that they're using nonces to make sure only authorized actions can happen (no cross site scripting), and they're checking user permissions too, limiting access to only admins. So why am I being pedantic? My default reply:
    Admins are humans. Humans make mistakes. Computers do exactly what they're told to do. 

    Admins Are Humans

    I'm often a broken record, telling people to sanitize, validate, and escape. When people ask me which sanitize function to use in WordPress, I play Socrates and walk them through the logic process. What kind of data are you saving? What will it look like? Okay, now what of these looks the most appropriate based on their descriptions? Sanitizing data is contextual. By this I mean we sanitize for what the saved data should be. If you're saving an email address, make sure you sanitize for email and so on. This has a side benefit of helping validate your data as well. If you check that the email address entry actually is an email, you're both sanitizing and validating. Now you've prevented someone from putting in a domain instead of an email!

    Humans Make Mistakes

    The details of 'best practices' for coding change often, as we learn about how to make code safer and smarter. That said, the ultimate best practices have nothing to do with the language you're writing in, the app you're writing for, or even the platform!
    • Restrict access to only the people who need it
    • Sanitize and validate the data you're given
    • Provide helpful error messages
    • Test your code with good and bad data
    • Document what the code does and what the errors mean
    Those practices transcend every single minutia of programing. If you do those five steps, your code will be robust, sane, and safe. Because you will have taken the steps to ensure that humans can make as few mistakes as possible. You don't save 'Dog' when true/false is the only valid answer.

    Computers Do What We Tell Them To Do

    The real problem is that AI doesn't exist.
    Source: CommitStrip.com
    Computers can't think for themselves, and humans have a tendency to stop thinking at weird moments (or just go on auto-pilot) which means nothing can destroy work faster than a human. And since a computer does what it's told, the most dangerous computer tool is the one that doesn't account for how big a mistake a human can make.

    Sanitize, Validate, Escape

    Especially when it's an admin.