Tag: Security

Not everything needs to be secure

Just saving this for future reference. I got on the “all HTTPS all the time” bandwagon without questioning it, because enough of the sites I create do collect user data that needs to be secure. But some — like this blog, for instance — do not.

But here’s an angle on it that I hadn’t considered:

If Google succeeds, it will make a lot of the web’s history inaccessible. People put stuff on the web precisely so it would be preserved over time. That’s why it’s important that no one has the power to change what the web is.
— Dave Winer

Google of course is always trying to change what the web is, just as Facebook does. I really got into a lather over AMP because it was immediately clear to me as a web developer how it is bad for the open web. Forcing everything to HTTPS is not quite as obviously “wrong,” but when you investigate it… yeah, it is.

This site uses HTTPS because… well, why not? I use Let’s Encrypt, so it’s free and easy. And I configured the server to automatically redirect HTTP traffic, so old links still work. But people shouldn’t be expected to understand what I understand about the web in order to use it… and not just as passive consumers, but as active contributors.

That’s the real power of the web, and what we lose when we let companies like Google or Facebook change the nature of what the web is.

I’d like to end with another quote from Winer:

The web is not safe. That is correct. We don’t want every place to be safe. So people can be wild and experiment and try out new ideas. It’s why the web has been the proving ground for so much incredible stuff over its history.

Lots of things aren’t safe. Crossing the street. Bike riding in Manhattan. Falling in love. We do them anyway. You can’t be safe all the time. Life itself isn’t safe.

Two-factor authentication is not the solution to the inherent flaws of password-based security

Uh, I really don’t have much more to say than that.

OK, maybe a bit. As a web developer working in client services, at least once a week I am confronted with the situation of having to log into a client’s account for something… MailChimp, GoDaddy, etc.

Many of these services have switched to 2FA-by-default, which I agree is more secure than plain old passwords (which I bet some of them still store in their databases as clear text). But 2FA is a pain in the ass. Especially when you’re in my position, and the phone number or email address that receives the one-time authorization code belongs to the client, not me.

Any time I need to log in, it requires coordination with the client to be sure they’re available to pass along the code to me. Which is just stupid.

Fortunately a lot of these companies have realized how common this kind of situation is, and how it’s a valid scenario, and they’ve worked around the limitation by creating “teams,” so clients can add me to their account as my own separate user, with my own login credentials, and my own 2FA.

But it’s still a pain in the ass. And not every service offers it. For example, MailChimp used to allow up to 3 users, I believe, on their free accounts, but now it’s just one. Of course, of course. Just pay for the service, right? Well sure, but service providers with a free tier imposing such a ridiculous limitation on that free tier as a way to upsell the paid tiers is kind of self-defeating. “Hi, we’re creating a crappy experience for you, and that’s the only experience you’ve known with us. But if you start paying us, we’ll make it not-crappy. We promise!” OK.

But it’s not really MailChimp’s fault. It’s that 2FA sucks. It’s more secure than plain ol’ passwords, but it’s even less convenient.

And while I’m ranting futilely, why do we even need security at all? Because people suck, period.

…

While I was writing this, I was waiting for a client to send me a 2FA for MailChimp. I’m in! And fortunately, this particular client is on the paid tier, so I was able to add myself as a user. A process which involved… wait for it… a CAPTCHA! (Time for another rant.)

In defense of WordPress

There’s a lot of negative talk circulating regarding the security attacks currently underway against outdated versions of WordPress. One of the most outspoken critics, not without cause, is one of my favorite bloggers: John Gruber of Daring Fireball.

That Gruber is loyal to Movable Type perhaps influences (despite his claims to the contrary) the tone of his assessment of the situation. And, I’m sure, my loyalty to WordPress influences my assessment of it as well. WordPress is not Apple, but I hold both in perhaps unduly high esteem.

That said, there are easy (or, at least, prudent) steps one can take to keep WordPress secure against this attack. Also, security is not the only (nor, dare I say, anywhere near the most important) factor in selecting a blogging platform. I’ve worked a fair bit with Movable Type, and while I can’t speak to the relative security of the two applications, I definitely can speak to their relative ease of use, and in that regard, I see no comparison: WordPress is surprisingly consistent and intuitive, given its open source nature and the large size of its developer community, whereas Movable Type seems to live in its own world where up is down, left is right, files are assets, and you need to rebuild the site every time you change anything. (Caching, if it’s even necessary, should be invisible to the user.) And then there’s the proprietary markup language.

It is unfortunate, and a weakness of the system, that WordPress has come under attack in this fashion. I’m glad that the latest version, at least, is immune to this exploit. But to dismiss WordPress because of this seems to grossly miss the point. And, debate this if you like, I do believe that if you’re not prepared to keep your installation updated, you shouldn’t be hosting the site yourself anyway. Use WordPress.com — it’s free, and it’s always up-to-date. The biggest victims here, I fear, are site owners who have relied upon an apathetic hosting provider to manage their system, and whose sites have been left vulnerable through no fault of their own.

All of the room34.com sites are running 2.8.4, and none has fallen victim to these attacks. But this incident did inspire me to take an action I had been neglecting — last night I dug into my httpd.conf file, shuffled a bunch of directories around on the server, and consolidated all five of the WordPress sites I’m running down onto a single installation of the software, so from now on I’ll only need to update once instead of five times. I probably could have migrated to WordPress MU, but it was an interesting experiment to take the approach I did, and it allowed me to avoid having to merge databases.