Code Review: Twitter but Shitter

Opening up the brief for this weekend’s challenge was a little daunting.

Make Twitter.

Oh yeah sure, let me grab a tea, a couple of years more experience and I’ll be right on it.

A big part of the challenge was to cement what we’d achieved over the last week, where we created our first real web app. It gave us all the chance to hone our understanding of the key concepts – databases, ORMs, MVC and user authentication/security.

Just putting it out there, but my attempt – Chitter: Twitter but Shitter – probably represents my biggest technological leap since I bust out the WordArt drop shadow in Year 9 IT class. It’s also the first thing I’ve made at Makers that I could legitimately show my mum and not suffer the reply, “A whole two days? This?”.

(Yes, I do realise you can just play Rock Paper Scissors with your fingers, Mum. But I remain unconvinced that version would withstand rigorous code review.)

As you can tell, this was also the weekend I experienced the life-affirming reward that comes with a smattering of CSS. A little text-align here, a cheeky padding there and suddenly I’d discovered a whole new level of what I like call ‘minimalist design’.

This level was blue.

If you want to, you can actually full on sign up to Chitter and post peeps of your own! I deployed the app to Heroku so you can visit it here. It’s kinda absent lacking in the mobile optimisation department at the moment so, unless you’re on a laptop/desktop, the experience may be slightly… let’s say… underwhelming.

You can also check out my code on GitHub, if that’s what you’re into.

Making a hash of it

Ok, now I’m done with the self-congratulation, let’s get down to the meaty stuff.

Chitter allows users to sign up with an email and password, log out and log in again if a matching email and password are provided. This may sound simple – most apps have this functionality – but there’s a hell of a lot going on underneath the scenes with regards to information security/user authentication.

First, as explained in my previous post, we used DataMapper to create and populate a table of users and their information provided on successful sign up. However, it would be pretty silly to store users’ passwords in our database as plain text objects, right?

Right. And the way to do this is through password hashing and salting. Password hashing makes use of super clever one-way functions, that turn text into long strings like such:

Screen Shot 2016-09-15 at 13.53.56.png

The good thing about hashes is that even if you have very similar passwords, their hashes will be completely different. Also, you can’t ever reverse a hash, so the original password is never stored and cannot be backwards engineered.

Salty hashes

However, hashing is not infallible. Passwords that have been hashed are still extremely susceptible to brute force attacks, dictionary attacks and attacks using ‘rainbow tables’. These are discussed in greater detail in this awesome blog post, but all make use of one big flaw: using the same algorithm two identical passwords will be hashed identically. This means a hacker can apply the algorithm to a dictionary of common passwords and match the resulting hashes to the hashes stored in your database. Hey presto: they now have all your emails and passwords.

To get around this problem, we have to introduce a ‘salt’ which is simply a random string of characters appended to your plain text password. Salts are randomly generated each time a password is created and, critically, identical passwords do not receive the same salt.

Now, when we want to authenticate a user, we just take the following steps:

  1. Take the plain text password a user enters on log in and append the unique salt (which has been stored in your database on sign up)
  2. Hash it all.
  3. Check the resulting hash against the one we have stored for the user.
  4. If it’s a match, the user is authenticated.

This is really great, but unfortunately salts do not and can not entirely prevent brute force attacks. Obviously, if a hacker wanted to, they could check every possible salt combination. Fortunately, BCrypt has a little trick up its sleeve to make it that bit harder for the bad guys:

Being real slow

Sounds pretty strange in a Moore’s Law -driven-tech-world to praise something for its slowness. But that it exactly what makes BCrypt so powerful. Using BCrypt allows you to decide upon how slow (and hence how expensive) your hash function is. The basic idea is that you can slow your hash function down to a level that doesn’t impede the client side experience, but makes brute force attacks completely unworkable – they just take too long.

Anyway, in conclusion, it’s all very interesting stuff. Excitingly real life and mathsy at the same time. In essence, the ideal bedtime reading material… No? Just me? Ok.

Advertisements

2 thoughts on “Code Review: Twitter but Shitter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s