Tag: security

HTTPS and HSTS
HTTP Strict Transport Security (HSTS) is a standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS.

Basically you have your server say “Everyone who accesses my server should use secure connections.” This matters because it prevents man-in-the-middle attacks that change HTTPS to HTTP and steal your credentials. Bad days. If you are using HTTPS/SSL on all your domains you should totally enable HSTS.

Okay, great. How?

Well if you have one domain, this is as easy as tossing this into your htaccess:
```
 <IfModule mod_headers.c>
    Header set Strict-Transport-Security max-age=16070400;
 </IfModule>
```
But … I have 20+ domains on this server. That would suck to have to edit! In fact, this is really closely related to my issues combatting referrer spam server wide. This stuff isn’t always obvious. For cPanel, I just added that code to my pre_virtualhost_global.conf file, same as I did for a certain referrer spam company.

If you’re using NGINX, you should read their blog post on the subject for full details but the basic code is this:
```
server {
    listen 443 ssl;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # This 'location' block inherits the STS header
    location / {
        root /usr/share/nginx/html;
    }

    # Because this 'location' block contains another 'add_header' directive,
    # we must redeclare the STS header
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}
```
And if all else fails and you can’t set this on the server, you can always edit your .htaccess or nginx.conf file locally.
31 August, 2016
Let’s Encrypt cPanel
On August 10th, cPanel announced provisional support for Let’s Encrypt via AutoSSL.

For hosts like DreamHost to be able to implement Let’s Encrypt is a lot easier than a behemoth like cPanel. See, DreamHost only had to make sure it worked on their own servers. They have a homegrown panel that they have 100% full control over. Adding in how to install the code on all servers and how to integrate it requires less testing than cPanel, who has to make sure everyone who uses cPanel can use this.

As of version 58 of cPanel, everyone can. And it works.

Installation

Log in via SSH and run this as root:
```
$ /scripts/install_lets_encrypt_autossl_provider
```
That installs everything you need. Keep in mind, this only adds LE to the AutoSSL feature. It’s AutoSSL that whips up SSL certificates for cPanel accounts. Doing this install does not install certs on your domains. We have to configure it for that.

Configuration

Once you’ve installed the code, go to WHM: Home » SSL/TLS » Manage AutoSSL and set it to Let’s Encrypt:

If it’s your first time, yes, check Create a new registration with the provider. because you’re new. You only need to mess with that if you’re new or have to reset registration for some reason.

By default, AutoSSL is set to run based on your “Feature List Setting” (under Home » Packages » Feature Manager » Edit Feature List). Mine has it checked, which means it will automatically run.

Adding Existing Domains

This worked great except I had a bunch of domains using StartSSL. First off, I adore StartSSL, and the recent changes to their website make it so much easier to use. But I was using it for external free certificates where I didn’t want to pay for them, on domains that never see money. Some of them (most of them) I wanted to convert to LE.

For that, I deleted the StartSSL certificates in WHM and cPanel for the domains/account in question. Then I went to AutoSSL, clicked on the tab “Manage Users,” and clicked “Check USERNAME.” I did not pick check all users (which is at the top of the page) because I don’t want to check all users.

Adding New Domains

I love this part.

Do nothing.

No, really. Add the new domain, wait twelve hours, boom. New certificate. If you have to have it right now, go into WHM and click check for that user. But it’s automatic. Hence ‘Auto’ SSL you see.

Caveats!

This is something only controlled by the server admin. Per-site cPanel doesn’t get an option, however if they delete the LE cert and add their own, that will override it.

There’s a limit to how many times you can make certificates and how many you can make. As the warning says:

Certificates that Let’s Encrypt provides through AutoSSL can secure a maximum of 100 domains per virtual host.
Let’s Encrypt will issue a maximum of 20 certificates per week that contain a domain or its subdomains. If you include subdomains of a domain on more than 20 certificates, Let’s Encrypt will issue those during the next window, up to the limit for that week.

If you’re using a wildcard subdomain (*.ipstenu.org for example) in order to make things easier with Multisite, this won’t work. You’ll see a ton of errors in your logs. Not to mention it won’t make SSL certs for all the virtual subdomains. That’s because they’re too virtual. You’ll have to make an actual add-on subdomain or use a domain alias for LE to pick that up.

You can’t revoke a certificate either, which can be a problem should there be a security issue along the lines of Heartbleed. When that happened, we all had to reset our SSL certs as well as patch our servers. Lots of fun. Should that happen again, cPanel users will have a big problem.

It’s because of that I don’t want to use Let’s Encrypt on everything. I’ll use it on this domain, and my other normal ones, but my WMH domain and my stores use a Comodo Certificate.
19 August, 2016
Whose Fault Is The Hack?

Your site was hacked.

Welcome to the worst day of your webmastering career. This is worse than the time you accidentally rebooted the server in the middle of processing the largest orders ever. This is worse than the time you cowboy coded something stupid at 1am on your phone from the bar. This is worse than the time you typed rm -rf ./* in the wrong window. This is worse than the time your credit card expired and you put off fixing it in the billing system until your site was down.

Why? It’s worse because you have no idea what the hell just happened, why, or who to blame.

Let me tell you who to blame.

Your Web Software

Oh yes. They are to blame. They left you vulnerable. They made it all sound so super easy and simple that you installed a site and walked away, assuming all was well. They didn’t push those security updates like they promised and they left you ready to be hacked!

Except… Did you update everything promptly? Did you use the code only in the ways it was intended? Did you add on extensions that weren’t vetted by security experts. Did you limit the administrative access to your site to only people who knew how to do things and what was, and was not, safe?

Your Web Host

Can’t forget these idiots, right? They’re supposed to be locking your server down for your own protection and making sure no one can see anything. They take care of everything, like server updates and network upgrades and those zero-day SSL alerts. Clearly they dropped the ball.

Except … Did the OS they’re using actually push the update needed for security? Did they not and now your host had to decide if they fork and support more or they wait and only support the legit things? One is getting you fixed faster, but it’s also making it harder to make sure all security patches are applied. Oh and hey, there are 40 other people on your slice of the network, and one of them has a down-time requirement. And did you remember to only use the secure access to your server? Did you maybe, the one time, turn on FTP (even though they told you not to) and use a clear-texted password?

Yours

Hey you. If you can’t tell… The answer is it’s everyone’s fault.

Of course everyone can do better to make the world more secure, but we have to accept the fact that it’s not ever any one person’s fault. Very few bits of code are written by one person and never looked at. Very few situations are clearcut. We forget to lock the door, we leave a window cracked, we assume and don’t check.

But at the end of the day, the fault for our hacks lies on the person who cares the most when the hacks happen. If your website is your life, if it’s the way you make business and survive, you cannot just take it all on a hope and prayer that you got it right. And if the effort of upkeep and maintenance is too much, you’ll have to compensate with paying for experts who do that.

The fault is ours.

29 June, 2016
Baby Steps Security

It’s a simple question. How do I make my site login secure?

My answer is simple. Use https for your admin dashboard and use a strong password.

Your username is not a secret

My gmail user ID is ipstenu@gmail.com

My WordPress.org username is Ipstenu. So is my Twitter handle. Facebook? Yep. GooglePlus even.

And my username here on this site is Ipstenu.

I hear a lot of people telling folks that their username on their WordPress blog should be a secret and, for the life of me, I can’t understand the logic. Your username is not a secret. It never really has been. It never will be. We used to log in everywhere with our emails, then it became our commonly used nicknames, and based on Twitter and Peach and whatever social network comes next, that’s where it’s going to remain.

But… Admin?

But why do people tell you not to use ‘admin’ as your username, then? Well it’s the same reason you have a top lock and a knob lock on your door. The knob lock is your username. Everyone has one, and they have roughly the same level of protection. If you only use a knob lock and don’t have a good top lock, the brute force of someone kicking your door in is pretty easy.

The top lock, the bolt and chain, that’s your complex password. Not everyone uses them. You should, but some of us are lazy. When we do use them, we make our lives more secure and safe.

Back to admin as a username. Using admin is like using the same key for all the doors in an entire apartment building. If you’re the apartment owner, that sounds great. But if you’re the resident, you’re probably not super happy about that idea, right?

Changing your username to something unique to you makes your lock safer. Reusing it means you have the same master lock for all your accounts. It’s better for you, you can remember it, and it’s sneakily helpful for your branding. Yeah, I slipped SEO in there.

But your passwords are a different matter. You don’t want to reuse your passwords for a simple reason: If you do reuse your passwords, then once someone gets one password, they can get access to all your accounts.

All. Your. Accounts.

Your bank account.

Two Factors

A lot of this is mitigated by something called Two Factor Authentication, which gives you the ability to have a username (publicly known), a password (private and secret), and a one-time-use password (generated by an app and only good for 60 seconds or so). Now you have three locks! One of which you don’t even know how to open until you’re actually opening it.

The current issue with Two Factor Authentication is its usability. It can be confusing to people to set up. You need a smart phone, which are not universal quite yet, and you need to be able to take a picture of your screen for most of them. Even once you have it set up, you need to read and enter a code.

I’ve found mixed information regarding how well this works, or doesn’t, for people who are visually impaired. For the most part, I suspect these tools are only barely accessible. They’re probably a nightmare for the blind to use. If you have to rely on getting a text message to log in, then you’re absolutely fucked if you’re overseas or out of range or have no bars.

And then there’s the issue I see faced by everyone, and that would be what happens when you lock yourself out. If you [get locked out of Apple](George’s link), it’s a headache but survivable. But if you get locked out of your own site, what do you do? Who do you call? Your webhost? Why? It’s not their responsibility to unlock you. And don’t ask WordPress.org to unlock you.

No, you have to know how to do ‘something’ to fix this. Be it disable a plugin without being logged in, or be it editing a file, you will need access to your system and some technical chops to pull this off. And no, folks, the majority of WordPress users don’t have it.

Security in Steps

We cannot all become secure tomorrow without possibly alienating the user base. WordPress has a 26% market share these days, and that’s a non-insignificant number of people. For them, we absolutely must consider the cradle to grave usability of our products. How useful are they? How safe are they? How easily can someone untangle their site?

Two Factor is one of the ways to go, but it’s only one possible future. It has a higher hurdle than many people understand. Even Google has a less than 10% adoption rate for 2FA. Facebook probably has less, and if I was asked which user base most matches the skill level of the average Wordpress user, it would be Facebook.

WordPress faces a hurdle of its own creation. It’s too popular with too many people of questionable technical ability to just switch on two factor authentication and force it for everyone. Much like multisite, it requires an understanding of some technical aspects of the web, not WordPress, to use safely.

Or as my friend Jan puts it: You must be this tall to ride.

24 February, 2016
Apple Does the Right Thing

People died. While we can easily get lost in the implications of preventing deaths and understanding why a mass killing happened, there is one fact we’re left with.

The FBI have asked Apple to write a backdoor into the iPhone code to allow the FBI to brute-force entry into an iPhone.

What is Brute Force?

Quite simply, it means trying passwords over and over again, until the right one is determined. At its heart, it’s trial and error, and you can program it into another computer. We call it brute force because rather than trying to intellectually deduce a password, it’s done via direct effort.

Why does this involve Apple?

You can set your iPhone to, after 10 incorrect passwords, wipe itself out. After three (3) wrong passwords, the iPhone makes you wait a little. I’ve set my phone to wipe on 10 incorrect passwords since if someone has my phone and can get in, they can also get access to my banking information.

With a 4-digit passcode, there are 10,000 possible permutations. With 6, this increases to 1,000,000.

The Ten most common passcodes have probably been already tried. And if you want a fun read, check out Why repeating a digit may improve security on your iPhone’s 4-digit lockscreen PIN.

What did the FBI actually ask?

I have read a copy of the summary (this is not the full 40 page ruling) and many of the news articles. The best I can summarize is this:

Tuesday February 16th, 2016, a magistrate judge in Riverside, California ruled that apple had to provide “reasonable technical assistance” to the government to recover data from an iPhone 5c. This includes bypassing the auto-erase function (the one that happens after 10 bad passwords) and allowing them to submit an unlimited number of passwords. In order to do this, the FBI wants a special version of iOS that only works on the one iPhone.

Apple has five days to respond if they believe that compliance would be “unreasonably burdensome.”

Yes, it says that the FBI is asking to break into one iPhone, but the only way to do that is to write a system that could be used to backdoor any iPhone. This is because Apple intentionally wrote their code so that they couldn’t get at your data. Apple has no way to dismantle or override the 10-tries-and-wipe feature. Only someone with the passcode can do it.

Is that technically possible?

Of course. There’s no real question about that. It won’t be easy (so ‘unreasonably burdensome’ may or may not apply here). And to be honest, the technical possibility of this is not the issue either.

Does this mean ‘anyone’ could do this? Yes, but it’s unlikely. This sort of hack is an OS-level one, which means the software needs to be signed by a key only Apple knows, unless there’s some other vulnerability in the phone. You can introduce a vulnerability by jailbreaking the phone, of course, but for the most part we don’t know if you can hack it from the outside like that. Signs point to this not being probable. But if it was going to happen, Apple would be the best company to try. They’re the ones who would know best.

I want to stress: I believe anything is technologically possible. Human cloning? You bet! Hacking my iPhone? Sure thing. I do not believe these things are easy, or even probable, but they are in the realm of possibility.

Why did Apple Say No?

Apple did say no. They said it publicly in a Customer Letter on their website. And they said no, not because these things are hard, but because they are dangerous.

Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.

[…]

Rather than asking for legislative action through Congress, the FBI is proposing an unprecedented use of the All Writs Act of 1789 to justify an expansion of its authority.

The government would have us remove security features and add new capabilities to the operating system, allowing a passcode to be input electronically. This would make it easier to unlock an iPhone by “brute force,” trying thousands or millions of combinations with the speed of a modern computer.

The implications of the government’s demands are chilling. If the government can use the All Writs Act to make it easier to unlock your iPhone, it would have the power to reach into anyone’s device to capture their data. The government could extend this breach of privacy and demand that Apple build surveillance software to intercept your messages, access your health records or financial data, track your location, or even access your phone’s microphone or camera without your knowledge.

You can read the whole thing for yourself, but in essence Apple is saying that by allowing the FBI to insist on this, they can use it as leverage to demand anyone’s phone be unlocked similarly. Keep in mind, while this case is certainly above board, do we really trust our government to always have our best interests in their hearts? Where can we draw a line between a known criminal act and a suspected one? Do you think they will never apply this to a case with tenuous links to an actual crime? We’ve already had wiretapping issues (Watergate, need I say more), and frankly the US government hasn’t gotten much better. And once the US has managed to allow this, many other countries will use this as their reasons to do so.

Also you can’t uncork the lamp. Once the genie is out and this is possible, it will be given out to other agencies and someone will reverse engineer how this works. Other countries will get their hands on this. They will use it against innocents. We know this is truth because it already happens now.

Privacy and Freedom

I’m going to give you the quote you’re expecting. The Ben Franklin one:

Those who surrender freedom for security will not have, nor do they deserve, either one.

From a technical aspect, the hurdles faced to hack into a cell phone make me feel safer as a user. It makes me feel better to know that the FBI are failing to break into my little iPhone.

22 February, 2016
Mailbag: Access and Security
In the midst of a longer set of forum posts about how to not have a plugin updated because you’ve made edits to the plugin, someone said that their issue was that the people on the site updated.

Now please don’t say that we should give them minimum privileges …

Actually. That’s precisely what I’m going to say.

1) Do not make anyone an admin whom you do not explicitly trust.

2) As the admin, test all plugins before updating.

3) If a plugin is constantly releasing unstable updates, stop using the plugin and look for alternatives.

3a) But make sure it’s not your theme or a conflict with another plugin first. It may be something else’s fault.

4) Stop editing plugins directly.

5) Treat every upgrade as a serious thing.

Now. I know why the guy doesn’t want to hear “You’re doing it wrong.” But the truth is this. If you give people who are irresponsible enough to update things the ability to update things, they’re gonna update things!

True story? On one of our company sites, one of the guys has access to update all the things. He did and broke the site. I jumped in, told him “Don’t do that, please, ask me next time.” and I fixed it. And then I went through everyone who had admin access and locked their accounts down to Editors. The exceptions were the people who legitimently needed that access.

And yes, WordPress needs more granular user roles/controls. I want that user to have access to administer all posts and add new users. I don’t want him anywhere near the plugins and themes. But I evaluated the risk vs reward of his access, and since he’s educatable, I felt it was safe to leave him there. Plus he knows right away to call me if he breaks things.

That goes back to the trust aspect, though. I trust him.

Trusting people to have access to aspects of your site reflect your understanding of what that access means. Making everyone and their brother an admin is reckless, not to sugar coat the situation. Only people who must be admins should have admin access. It’s really that simple. And if you insist there’s no other way around it, then you’re not paying attention closely enough.

Make a list of what your users need to do. Not what they want, what they need. And be serious here. Do they need to update plugins or do you do it for them in a reasonable timeframe? Do they really need to be able to add users? Remember though, we’re asking what they need, not you. Go to WordPress’ list of Roles and Capabilities and take note of what they actually can do.

Now I said before, the roles and controls and capabilities of WordPress leave a lot to be desired. But thankfully WordPress has add_cap and you can adjust roles.

Here’s how Isabel Castillo did it:
```
function isa_editor_manage_users() {
 
    if ( get_option( 'isa_add_cap_editor_once' ) != 'done' ) {
     
        // let editor manage users
 
        $edit_editor = get_role('editor'); // Get the user role
        $edit_editor->add_cap('edit_users');
        $edit_editor->add_cap('list_users');
        $edit_editor->add_cap('promote_users');
        $edit_editor->add_cap('create_users');
        $edit_editor->add_cap('add_users');
        $edit_editor->add_cap('delete_users');
 
        update_option( 'isa_add_cap_editor_once', 'done' );
    }
 
}
add_action( 'init', 'isa_editor_manage_users' );
```
You only need to do that once since the roles and caps are locked into the database (see above, the controls need to be better). Still. Now your editors can edit users. Brilliant.

So yes. I will tell you you’re doing it wrong, especially when you’re doing it in a way that is dangerous and risky in the long run.

Don’t let the toddlers try to drive the car.
8 January, 2016