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:
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.
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.
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:
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.
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:
I also have a couple of commands I run every time I setup a server, because nano is the bane of my existence:
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:
Now edit /etc/sudoers:
And add your ssh key:
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:
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.
You can edit /etc/nginx/nginx.conf if you want, but mine tends to stay pretty standard:
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:
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:
Then reload your environment:
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:
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.
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:
Then set it up:
Then all it takes is a single command:
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;
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;
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.
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:
The important aspects here are you must include the keywords ‘ember-addon’ and, if you don’t want to publish your code, set ‘private’.
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’.
And the Shared Addon is now setup.
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.
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.)
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:
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.
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”.
Who am I? I'm Maddison Joyce. I've worked in all areas of software development and before that I was in tech support. I love writing code, learning new technologies, reading books and talking to people. I can help you with your next software project.
© Maddison Joyce, 2014.