I’ve got another confession to make- I’ve relied on user/password libraries for far too long. It’s not a particularly glamorous or enjoyable part of web/app development, so I inevitable turn to some kind of library to do the storing, the comparing and I focus on the pretty colours for the login page.

That sinking feeling in my gut is probably linked to the thought that leaving password storage, encryption, etc. to a third party attack might be why Ashley Madison is having some ‘issues’. However, that’s probably not the reason I’m thinking about this. Recently, I’ve been playing with node.js and express as an alternative to ruby and rails, whilst watching the Handmade Hero video series.

Quick Sidenote: Express isn’t really comparable to Rails, it’s more like Sinatra- very lightweight with an absolute crapton of plugins.

I was inspired by Casey Muratori’s approach to game making (even though I never want to program a game), which goes very low level in understanding and implementing concepts and code. At the same time, the express library is incredibly unopinionated (with requirejs allowing any kind of modularity you could wish), so it allows me to go to similarly low levels in implementing a new web app.

So, on with the show. Here’s the sum total of my knowledge on passwords and encryption and what not:

• Don’t store passwords in plain text- This one might feel like a no-brainer but apparently it’s not for everybody.
• Not all hashing functions are created equal- I knew this, but only as a kind of mantra. Having now read Coda Hale’s Article, I think I get it, but more on that later.
• Salting- Is the process of adding a unique string to the start of the password before hashing it.

And that’s about it. Beyond knowing I could download the BCrypt library for a given language, I really don’t know much. That’s when I decided to do some research. I’m still no expert, but here are some of the attacks, and ways to stop them.

A Script that tries to Login

Let’s say you’ve got a simple email and password login screen. Our malicious attackers already know the user’s email address but not the password. Put simply, these attackers might try a whole lot of passwords on that one username. To stop this, most sites implement a lockdown/password reset after a number of incorrect attempts.

Accessing the database records

Alright, let’s go a little deeper and say you forgot to change the user on the database from admin:admin and now the malicious attackers have downloaded your user table.

If you kept the passwords in plain text, well that’s it, but we’re good database admins and we’d never do that. Right? Right?

We’re slightly better database admins now, we’ve encrypted our passwords with MD5. Our attackers aren’t silly, they can tell we’ve used MD5, so they use a little trick called Rainbow Tables. Instead of testing the passwords on the spot, they generate the MD5 hash of a pile of passwords before hand, and check to see if your hashed value matches one of them. By doing this, they can significantly reduce the time taken to crack a password by implementing a large table instead of continuously determining the value.

So, with that knowledge, we implement our salt. We store it beside the hashed password in the table (so our attackers have it too). Unfortunately, your average computer with a decent graphics card can compare 2.8 trillion passwords hashed with MD5 or similar every second, so the attackers might not be able to prepare the rainbow table in advance, but they should have a pretty easy time of cracking the password.

What’s the answer then. As far as I can tell, it’s called key stretching- and basically it’s purpose is to slow down the process. We still use a salt (otherwise rainbow table would still cause problems), but we use an algorithm that takes a significant amount of time (for a computer) to process, generally around a second. If I’m a user logging into your site, a second isn’t particularly noticable. But if the attacker to try 2.8 trillion passwords to guess yours, it will take 2.8 trillion seconds (around 80,000 years). That’s not bad.

There are a couple of algorithms/libraries that do this. Bcrypt, Scrypt and PBKDF2 are they ones I know of. Importantly, they also include what they call a cost factor, a number which increases the amount of time taken to perform the action. This means even as technology improves, these algorithms can continue to be useful by increasing that cost factor.

Now what? Well, I’m probably going to go and download that BCrypt library. But if I’ve scared you significantly enough to worry about how your own passwords are being stored, there are a few things you can do:

• Don’t reuse passwords- You can’t trust the website you’re using, no matter what. So don’t use the same password in two places, or one cracked account will lead to a lot more.
• Keep them long- [How Secure is my Password?][https://howsecureismypassword.net/] is a great website for understanding the value of a long password over just a varied password. Use sentences with punctuation and numbers in them to improve the strength.
• Don’t write them down- The temptation is strong, but if you want to keep all in one place, services like [keepass][http://keepass.info/] and [passpack][https://www.passpack.com] can be particularly useful. Make sure you understand what they’re doing and how they work before you start using them though.

Oh man, I’m getting that familiar urge again. It’s blog time. This should last all of a week. But this time, I’ve got a plan. I’m dedicating an hour every friday morning to writing something down. Doesn’t matter what it is. Even if it’s not that good, or that finished, I’m going to publish it here.

Now that that’s sorted, here goes my first hour…

For about the 5th time in the past 3 months, I’m in the process of setting up another deployment server to host my web apps and it’s starting to get that repetitive feeling. Every time, I think I should take notes and then everytime I forget to, so here goes.

In case you’re wondering, I’m certainly not the first to do this, so I turned to the steadfast wisdom of Lord Google ™ and read through a few articles. This post is my own concoction, but many chunks of it will feel familiar having read through the resources below.

My Resources:

• Jon McCartie’s Blog
• Vladi Gleba’s 6-Parter
• The Flying Developer

My Stack:

• Ubuntu
• Nginx
• Rbenv
• Unicorn
• Mina

Step 1- Get Yourself A Server

Hopefully you were expecting that. There’s plenty of choices, but I’ve used Amazon, Digital Ocean and now Rackspace. If you’re really keen, you could always build it yourself, but I don’t have that time on my hands.

Spec-wise, it’s really up to you, and you’ll obviously need to think about who’s using the server, but here’s my preference:

• Something with at least 1GB of RAM, for my unicorn workers.
• Storage can be pretty minimal, it only stores the rails app. I hate file uploads, so I tend to use carrierwave + some service (Imgur, CloudFiles, Dropbox, etc.).
• My preferred Server OS is Ubuntu. I’ve been using it since I was 7, it’s easy and I’m yet to find a reason to change. Generally, I’ll pick the LTS version, because, you know, it’s the LTS version.

I also have a couple of commands I run every time I setup a server, because nano is the bane of my existence:

apt-get update
apt-get install -y vim
update-alternatives --config editor
# Then hit the number for vim

Step 2- Get Yourself A User (And A Group)

Now the server’s up and running- or you’re still fiddling with a graphics card- let’s get a user for our deployments. You can use the root user, but that’s a bit dodgy. So let’s setup that user:

groupadd deployers
adduser deploy -ingroup deployers

Now edit /etc/sudoers:

%deployers  ALL=(ALL) ALL

And add your ssh key:

su deploy
cd ~
mkdir .ssh
cd .ssh
vim authorized_keys
# Paste your public keyfile (ssh-keygen -t rsa)

From here on, I’m just going to assume you’re logged in as the new deploy user.

Finally, make sure your server is up to date, and sort out time zones so you don’t have to work out what was happening at 3am later on:

sudo apt-get -y update
sudo apt-get -y upgrade
sudo dpkg-reconfigure tzdata

Step 3- Get Yourself A Proxy

In case you didn’t know- and because I didn’t- Nginx is actually a proxy server (which makes it a bit different to Apache). This is what makes it perfect for our use, we’ll setup Nginx to proxy requests to our unicorn workers.

sudo add-apt-repository ppa:nginx/stable
sudo apt-get -y update
sudo apt-get -y install nginx
sudo service nginx start

You can edit /etc/nginx/nginx.conf if you want, but mine tends to stay pretty standard:

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
  worker_connections 768;
}

http {
  # Basic Settings

  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;

  server_name_in_redirect off;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  # Logging Settings

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  # Gzip Settings

  gzip on;
  gzip_disable "msie6";

  # Virtual Host Configs

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

Step 4- Get Yourself A Ruby

There’s a whole thing out there about http://rvm.io/ and http://rbenv.org/ and which runs faster, jumps higher and all the rest, but I prefer to stay out of inane internet arguments for my own sanity. Right now, I’m preferring Rbenv, because it feels easier and lighter, but both are awesome, so go with your gut.

First we install rbenv and a bunch of dependencies:

sudo apt-get -y install git
sudo curl -L https://raw.github.com/fesplugas/rbenv-installer/master/bin/rbenv-installer | bash
sudo apt-get -y install zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libxml2-dev libxslt1-dev autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev nodejs libcurl3 libcurl4-openssl-dev

There’s a step in there that rbenv will tell you to do, but I seem to forget it all the time. Edit ~/.bash_profile:

export RBENV_ROOT="${HOME}/.rbenv"

if [ -d "${RBENV_ROOT}" ]; then
  export PATH="${RBENV_ROOT}/bin:${PATH}"
  eval "$(rbenv init -)"
fi

Then reload your environment:

source ~/.bash_profile

Now that rbenv is ready to go, install a ruby version (2.2.0 for me as of now) and bundler, because it’s awesome:

rbenv install 2.2.0
rbenv global 2.2.0
gem install bundler

Step 5- Get Yourself A Unicorn

It appears I got a little distracted here and forgot to update. This will be updated- soon, I hope.

Edit (2015-07-31): Ok, so it looks like this isn’t getting updated. I’ll guess we’ll find out how to do it next time I have to setup a Ruby-Rails-Unicorn-Nginx-Mina stack. That’s my bad.

Step 6- Get Yourself A Mina

I’ve always used Capistrano as my deployment tool (other than the dark ages of FTP) but I really like the look of Mina, so I’m giving it a try.

First, add the mina gems:

gem 'mina'
gem 'mina-unicorn', :require => false

Then set it up:

bundle install
bundle exec mina init

Then all it takes is a single command:

bundle exec mina deploy

I’ve been mucking around with Ember.js for about 6 months now and seriously enjoy working with it. The whole product is really easy to use (admittedly, once you get your head around it) and it’s fantastic. The product I’m working on at the moment consists of a 3 part system;

• API- A rails based JSON api. The rails app doesn’t have any views, but does use Active Model Serializers to generate the correct JSON. Ember.js has the Active Model Adapter built in, so it’s brilliantly easy to configure the 2 systems together.
• Admin- An Ember based administration web application.
• Web- An Ember based, customer facing web application.

I decided to keep the admin and web components completely separate so they could be extricated later on if need be, but about 3 months in I realized I was duplicating a hell of a lot of code. In some situations, I was copy-pasting entire files because there was so much crossover.

I considered rolling the two ember apps into one, but it still didn’t make sense to the way the apps are designed. I wanted them kept completely separate so I was going to make sure they were. My initial attempts included;

• Making the folder structure fit both applications- Don’t even bother. This was an absolute nightmare.
• Using symbolic links- I thought I’d hit the jackpot here, but there were 2 issues. 1. I do have some files that I only need on one site or the other, and 2. Node doesn’t like symbolic links.

Next I turned to Github, and had an answer within minutes. Robert Jackson to the rescue with ember addons.

So, I followed a couple of tutorials and instructions but there was nothing that fit exactly what I was doing, so it was a bit of trial and error. Anyway, without further ado, this is how it went.

My resources:

• Dockyard Blog Article
• HashRocket Blog Article

Step 1- Creating the Addon

The easiest way to setup an addon is using NPM, which worried me until I realized private NPM packages exist and are easy to setup. So, I created my folder ‘shared’ and added a couple of files:

package.json

{
  "name": "shared-addon",
  "version": "0.0.1",
  "keywords": [
    "ember-addon"
  ],
  "private": true,
  "devDependencies": {}
}

The important aspects here are you must include the keywords ‘ember-addon’ and, if you don’t want to publish your code, set ‘private’.

.bowerrc

{
  "directory": "vendor"
}

bower.json

{
  "name": "shared-addon",
  "dependencies": {
    "momentjs": "~2.8.2"
  }
}

These files aren’t specifically required, but I found I was using a lot of the same vendor code, so to manage dependencies, I pulled all of them back to the shared module and, to fit with ember’s settings, set the bower directory to ‘vendor’.

index.js

// This code from http://hashrocket.com/blog/posts/building-ember-addons
var path = require('path');
var fs   = require('fs');

function Shared(project) {
  this.project = project;
  this.name    = 'Shared';
}

function unwatchedTree(dir) {
  return {
    read:    function() { return dir; },
    cleanup: function() { }
  };
}

//'shared-addon' below is the same as the name for your node module.
Shared.prototype.treeFor = function treeFor(name) {
  var treePath =  path.join('node_modules', 'shared-addon', name);

  if (fs.existsSync(treePath)) {
    return unwatchedTree(treePath);
  }
};

//Here we add any imported javascript (e.g. momentjs, bootstrap)
Shared.prototype.included = function included(app) {
  this.app = app;

  this.app.import('vendor/momentjs/moment.js');
};

module.exports = Shared;

And the Shared Addon is now setup.

Step 2- Adding some shared files.

The ember addon structure will call ‘treeFor’ for a number of different files. I got a little confused here because it doesn’t match the Ember App setup exactly. As far as I can tell the distinction is based on file type more than anything else. My folder structure looks a little like this.

• /
• app (For javascript files)
  • adapters/
  • components/
  • helpers/
  • mixins/
  • models/
  • serializers/
  • transforms/
  • views/
• styles (For SASS files)
  • _partial.scss
• templates (For handlebars files)
  • components/

This tree gets merged with the application, so my files are available as if they were a part of the original application.

And that’s it. You’re all setup.

To include your addon in an ember app, it takes just one command:

npm install ../shared

(You can use a relative or absolute path here.)

One Last Caveat- Static Assets

Ember static assets are dropped in the ‘public’ folder, but this folder isn’t pulled across by ember addons. To combat that, I dropped my static files in an ‘assets’ folder in the addon and my ‘brocfile.js’ looks like this:

var mergeTrees = require('broccoli-merge-trees');
var pickFiles = require('broccoli-static-compiler');

var EmberApp = require('ember-cli/lib/broccoli/ember-app');

var app = new EmberApp();

var sharedFonts = pickFiles('node_modules/shared-addon/assets/fonts', {
  srcDir: '/',
  destDir: '/assets/fonts'
});
var sharedImages = pickFiles('node_modules/shared-addon/assets/images', {
  srcDir: '/',
  destDir: '/assets/images'
})

module.exports = mergeTrees([app.toTree(), sharedFonts, sharedImages]);

It’s a little messy, but it works and I can share my fonts and images between apps.

This isn’t the first blog I’ve ever started. Nor is it the second. I’ve always had this whisper in the back of my head that I should be writing a blog. Not for your sakes, mind you. More than anything, I think it’s to give the voices in my head an outlet of sorts, somewhere to reveal their innermost dwindlings. My intention is for this blog to updated regularly, but I don’t know how I’ll go with that. While I quite like writing blog articles, they do take time and I don’t have huge amounts of that available to me.

However, onwards and updwards, let’s at least get this post out of the way. The most obligatory of blog posts. The initial post. There are any number of topics bouncing around in my head, based on my current work with NGOs, Javascript MVCs and API based systems (and a specific love for TLAs). But for now, I think I’ll discuss an article that coincidentally appeared in my LinkedIn feed a couple of days ago. This article by Darren Rowse is a discussion on ‘Understanding your Reader’ to make blog writing easier. Obviously, this is quite easy for me:

My readership has a fairly solid base of not anybody, as well as a group of readers with specific interests in not existing.

Now that that’s done, let’s get down to the nitty gritty of imagining the readers who might be attracted to my blog and, on an even deeper level, what my purpose is with this blog. If I’m going to be fair, the ‘purpose’ of the blog is a little in flux still. Generally, the blog comes around when I’m rebuilding this website and it feels a little empty with just the one page. So I add a blog in. But I quite like the idea of writing regularly, to keep my skills up and get my ideas down on a page. There’s a lot of great content out on the web (particularly in the fields I’m in), but it would take you a million million lifetimes to read all of it, so I don’t expect there to be huge numbers of people clamouring to read my posts. However, I am tickled with the idea of someone reading my posts and being inspired or learning something.

So, who would I like to be reading my blog. People like me, more than anything. Young people who love new technology, are out there trying to be ‘entrepeneurial’ and people who want to have a future at the forefront of the tech world. On top of that, I’d like potential clients to see this and understand a little about the way I work, think and do.

Done! That’s my first blog post. Alright, as we speak, I’m setting an alarm for next week (Friday 11/7/14) because by then I’d like to have another blog post out. I’m thinking “An Exploration in Ember”.