Shock! Alarm! There’s actually a new post!
As you might have noticed, I’ve been inactive for the last year or so — things have been extremely hectic in the lab and I’m in the “crunch time” for my dissertation. More soon.
For those who don’t follow it already, I strong recommend reading Shall Not Be Questioned at http://www.pagunblog.com/ — Sebastian and Bitter keep up to date with pretty much all gun-related news and information.
Google Authenticator Plugin: I’m sorry, but it is not possible for you to import an existing shared secret. You must generate a new one.
Me: Really? That’s annoying.
GAP: Yup. Sucks to be you.
Me: Fine. *generates a new secret* Oh, there’s something I ought to tell you.
GAP: Tell me.
Me: I have root access to the database in which the secret is stored. *edits the appropriate entry in the database, thus restoring the previous shared secret*
I’ve transitioned the site to a new host. Everything appears to be working well, but if you have any problems please let me know.
More details soon.
Many of the readers here are also bloggers, and quite a few use WordPress.
If you host your own WordPress installation (as opposed to hosting with wordpress.com), you may be interested in the Google Authenticator plugin for two-factor authentication.
If you have an iOS (iPod Touch or iPhone), Android, or BlackBerry device that can run the Google Authenticator app, the Google Authenticator plugin can help significantly with your site’s security. Once you link the plugin and the device, your device generates a new time-dependent numeric code at regular intervals. To log into your WordPress blog’s account you’ll need your username, password, and the numeric code generated from the mobile device application.
This way, even if an attacker manages to acquire your username and password they are unable to log into your WordPress account because they don’t have the correct code. Now an attacker needs something you know (username and password) and something you have (the mobile device that generates the code).
Update: One can also configure a static password for applications that are not able to deal with one time passwords, like desktop or iPhone WordPress clients. Very cool.
I’ve enabled dual-stack IPv6 and IPv4 connectivity on this site. There should be no problems, but if you experience any please let me know.
A few days ago I posted about how I was going to be testing CloudFlare on this site.
Here’s a snippet of the stats generated since then:
(click to enlarge)
By caching static content (images, CSS files, JavaScript, etc.) at various datacenters around the world, the service has substantially sped up the response of my site (between 50-67%, depending on the day), as well as saving a not-insubstantial amount of bandwidth (which is nice, as I pay for bandwidth used).
About 10% of visits were known threats, usually comment spammers but occasionally automated exploit hack attempts and botnet zombies. These are blocked from getting to the site.
I’ve received no complaints from legitimate users, either by email or through the CloudFlare messaging system (it shows up for blocked visitors), which is an extra plus.
So far, things look quite promising. It may be more effective for more traffic-heavy sites than my own, but even for a small site like this one it’s saved a bunch of resources.
I’ve decided to test CloudFlare service on my blog.
It’s basically a DDoS-resistant caching service that should increase page loading speed for visitors.
In addition, it also detects potentially malicious traffic (ranging from spammers to botnet members) to the blog and will block them with a “challenge” page that describes why they were blocked and offer a CAPTCHA to proceed. While it’s supposedly quite good at not blocking legitimate users, it may inadvertently challenge ordinary visitors. If this occurs to you, please let me know (either by email or by filling in the appropriate field on the challenge page).