Encrypting and decrypting text with Alfred 2

Here’s a couple of Alfred 2 workflows that implement encryption and decryption via AES256, useful for doing things like sharing passwords.

Select some text (or copy it to the clipboard), and hit the encryption hotkey, and you’ll be prompted for a password; the encrypted contents will be copied to the clipboard.

Then when the recipient has the encrypted text, select or copy it, hit the decryption hotkey, and the original password will be requested. Then, the original text will be displayed and copied to the clipboard.

Encrypt.alfredworkflow

Decrypt.alfredworkflow

Screen Shot 2013 03 25 at 12 51 50

Screen Shot 2013 03 25 at 12 52 14

Read More

Easy inclusion of OpenSSL into iOS projects

Oddly, iOS doesn’t provide any OpenSSL implementation at all — If you want to do anything with crypto (like checking signatures, checksumming, etc.), you have to build in the library yourself.

I came across a great XCode project wrapper for OpenSSL yesterday, by Stephen Lombardo. This is an XCode project file that contains a target to build OpenSSL from source, and works with both Mac and iOS projects. I made some modifications to it, in order to make it work by just dropping in the OpenSSL source tarball, without having to dirty up your source tree with the extracted OpenSSL distribution.

Here’s how to use it:

  1. Download the OpenSSL source.
  2. Put the downloaded OpenSSL source tar.gz into the same folder
    as openssl.xcodeproj (I put it in Library/openssl within my project tree).
  3. Drag the openssl.xcodeproj file into your main project tree in XCode.
  4. Right-click on your project target, and add openssl.xcodeproj under “Direct
    Dependencies” on the General tab.
  5. On the Build tab for your project’s target, find the “Header Search Paths”
    option, and add the path:
    > $(SRCROOT)/Library/openssl/build/openssl.build/openssl/include

    (Assuming you’ve put openssl.xcodeproj at the path Library/openssl — adjust as necessary).

  6. Expand your target’s “Link Binary With Libraries” build stage, and drag
    libcrypto.a from the openssl.xcodeproj group.

Then, you can just import and use as normal (#import, etc).

Download it here

Read More

Firming up WordPress’s security

There’re thousands of articles out there describing how to secure WordPress better against attacks, but I still had a little difficulty with the nuts and bolts, so I thought I’d detail the process I underwent here.

I recently had a bit of a security breach – some lowlife broke into my account and injected some phishing stuff into my personal webmail software. Consequently, I went on a bit of a security binge and deleted some apps I wasn’t using much, changed all of my passwords to ridiculously long strings, and set up layers of HTTP authentication on my WordPress login/admin pages, the latter of which is described here.

The general idea is to make it hard to get to the login/admin pages in the first place, which should block some attacks.

The AskApache password protect WordPress plugin will do all of this for you, unless it thinks your webserver doesn’t have the supporting software. It failed for me on Site5, saying I lacked HTTP digest authentication support, which is actually not true, as it’s enabled. I couldn’t be bothered debugging it though, so I proceeded with the manual route.

Create the password file

First, I created an htpasswd file, containing a login and password. There’re many sites describing how to do this, but on the terminal, it’s fairly easy:

htpasswd -c /path/to/.htpasswd myusername

Note that it’s a good idea to put the .htpasswd file somewhere outside the web root – your account’s home directory is one option.

Protect the login page

I opened up the .htaccess in the WordPress root folder, and added the following:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
 
    require valid-user

Note that ‘ErrorDocument 401 default’ line – this is in place to avoid getting a ‘404’ error whenever you load up the login page. I’m not entirely sure of the details, but it seems that if the rewrite module is used (the thing that allows WordPress to define an arbitrary website structure, without needing physical files), then this causes problems with HTTP authentication.

Also, if you wish to protect access to the XMLRPC access point as well, you can add the following:

 
    require valid-user

However, if you do this, I’m pretty sure pingbacks (the WordPress-specific version of trackbacks) will no longer work. I think trackbacks will still be functional – as far as I know, they use a different access point. If you use a desktop blogging app, you’ll want to make sure it can handle HTTP authentication. I know ecto can.

Protect the admin area

Finally, I created a new .htaccess file in the wp-admin directory, which looks like this:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
require valid-user
Read More

Private Tags WordPress Plugin

The “Private Tags” WordPress plugin allows users to specify a list of tags or categories to keep hidden from the public – all posts within the specified tags/categories, and the tags/categories themselves, will not be visible to anyone but the original author.

Alternatively, in ‘inclusive’ mode specify a list of tags/categories to make public – all other tags/categories will remain hidden.

Read More

Links for December 29th through January 28th

Links for December 29th through January 28th:

Read More