Connecting to a VPN automatically when not at home

When I’m on my home Wi-Fi, I rarely connect to a VPN. When I’m out, I always make the habit of doing so, except when I forget. I was hoping VPN clients would have a feature to automatically connect based on a list of networks, but after some quick research, I guess not. Maybe I’m wrong, but ended up with this nifty solution. I’m currently using Viscosity as my VPN client, but should work similarly for other clients that allow some scripting.

Continue reading “Connecting to a VPN automatically when not at home”

Backup OpenPGP keys on paper

image

Recently I remember I was keeping a backup of my OpenPGP keys on an external hard drive that any day now could just cease to work. After my first attempts with PGP/GPG where I lost my private keys and could no longer revoke them, I wasn’t planning on loosing another one again.

After reading what others did to store their private PGP keys, I figured that the best way to store them was on paper. That’s where paperkey comes along. Paperkey is an OpenPGP key archiver by David Shaw, one of the main GPG developers.

What does paperkey do?

Due to metadata and redundancy, OpenPGP secret keys are significantly larger than just the “secret bits”. In fact, the secret key contains a complete copy of the public key. Since the public key generally doesn’t need to be escrowed (most people have many copies of it on various keyservers, web pages, etc), only extracting the secret parts can be a real advantage.

Paperkey extracts just those secret bytes and prints them. To reconstruct, you re-enter those bytes (whether by hand, OCR, QR code, or the like) and paperkey can use them to transform your existing public key into a secret key.

So to try it out, I installed it via homebrew.

brew install paperkey

Take the secret key in secret-key.gpg and generate a text file my-key-text-file.txt that contains the secret data:

paperkey --secret-key secret-key.gpg --output my-key-text-file.txt

I then printed the resulting text file and stored it somewhere safe.

To reconstruct secret-key.gpg, take the secret key data in my-key-text-file.txt and combine it with public-key.gpg:

paperkey --pubring public-key.gpg --secrets my-key-text-file.txt --output secret-key.gpg

I also stored a digital copy of my secret key on a new USB flash drive.

Bonus: You could also print a QR code of the paperkey output.

brew install qrencode
paperkey --secret-key secret-key.gpg --output-type raw | qrencode -o qr-paperkey.png

By the way, I’m in no way an #expert in PGP/GPG or security in general.

How do you backup your PGP keys?

Auth with JSON Web Tokens

image

When it comes to implementing authentication on web apps, one solution you’ll definitely hear about first are cookies. Cookie-based authentication uses a server side cookies to authenticate the user on every request. This means that you’ll need to keep a session store, whether it’s on a database or on something like Redis. A solution you’ll probably not hear as often is token-based authentication which relies on a signed token that is sent to the server on each request.

Alberto Pose over at Auth0 wrote a great blog post about Cookie vs Tokens, diagrams how both of these method works, and goes over the benefits of using a token-based approach for authentication.

There’s a relatively new standard called JSON Web Token that happens to be backed by companies like Firebase, Google, Microsoft, and Zendesk. There are already many libraries to handle encoding and decoding of this tokens in the backend.

After a couple of days of research I was convinced that this was something we could definitely use for Blimp 2. This new version will be an ambitious web application written on JavaScript. This means that there will be no HTML rendering from the server. The backend application will only serve a RESTful API that will be used by our own application as well as by developers working on third party applications.

The only difference when accessing the API will be the authentication method used. We’ll use JWT but third party application will use OAuth2.

The JWT Spec

JWT(pronounced “jot”) or JSON Web Token is a compact URL-safe representation format intented for space constrained environments such as HTTP Authorization headers and URL query paramaters. JWTs represent a set of claims as a JSON object that is encoded in a JSON Web Signature or JSON Web Encryption structure.

A JWT is represented as a sequence of base64url encoded values(with all trailing ‘=’ characters omitted.) that are separated by period characters.

The following is an example of a JWT Header

Base64url encoding of the JWT Header yields this encoded JWT Header value:

The following is an example of a JWT Claims Set:

Base64url encoding of the JWS Payload yields this encoded JWS Payload:

Computing the MAC of the encoded JWS Header and encoded JWS Payload with the HMAC SHA-256 algorithm(using the key ‘my_secret_key’) and base64url encoding the HMAC value, yields this encoded JWS Signature:

Concatenating these encoded parts in this order with period characters between the parts, yields this complete JWT.

You can read more about JWT in the submitted Internet-Draft.

An Example Scenario

First enters djangorestframework-jwt, a package I just released that provides JWT Authentication support for Django REST framework. It also provides an endpoint that can be used to obtain a JWT for a given username and password.

Once you’ve obtained a JWT, you can access resources that required authentication by passing the HTTP Authorization header.

A simple example of how this would be handled with jQuery and a Django REST Framework API endpoint with JWT Authentication.

And that’s a wrap!

And that’s basically it! I’d love to know what you think about JWT. Would you consider using token-based authentication? Any questions or feedback? Feel free to leave a comment.

Photo Credit: http://www.flickr.com/photos/number657/5179518226/