Brett, why are your car keys in the fridge?


“Well, it starts with the Japanese…”

This is the point that my co-workers either start grinning and backing out of my office or I see the whites of their eyes as they roll violently…

Poka-yoke is a Japanese term that means “mistake-proofing”.

Enough bullshit. What the hell are you actually talking about? Car keys in the fridge? Why?

Well, it’s pretty simple to explain:

I could easily (and often) get in my car, drive home and forget my shopping at work. However, it’s impossible for me to go home and accidentally leave my car at work.

Instead of creating work for yourself by creating one more thing to remember, put the action or object you need to accomplish directly in your path. You can’t forget if you have to step over or move the thing you need to remember.

  • Need to take something somewhere: Put it on the floor in front of the door you use to leave.
  • Can’t forget the important widget for the specific event: Put it in the shoe you know you’re going to wear when you’re at that thing.

Don’t use the limited and exhaustible mental processing power you have available to track the mundanities of life.

I’ll admit that I didn’t realise that what I had been doing over the years was rooted in the lean manufacturing methodology spawned by Toyota. I think I actually picked it up years ago from a podcast where Merlin Mann interviewed David Allen (the author of Getting Things Done)



Posted in Productivity | Leave a comment

Why businesses need to stop emailing passwords!


Every few weeks or so, a technical person on Twitter mentions to a business that they shouldn’t be receiving their login details in an email. It’s bad practice and not secure they scream… and the businesses carry on.

In this post, without being technology specific or going into too much technical detail, I’m going to highlight what sending passwords in emails says about these companies’ systems, why it’s not secure and what I think they should be doing instead.

First, a little background; email hasn’t fundamentally changed since the 1980s and is mostly unencrypted by default. As of last year, Google reported that 50% of the emails between them and other providers was unencrypted.

The passwords that businesses email are sent through in clear text, which means they can be easily intercepted and harvested on their way between you and the email servers. Passwords are vulnerable even if transferred over encrypted connections, as they’ll likely just sit in a person’s inbox forever, waiting to be compromised by any hacker smart enough to use a search function.

It’s also worthwhile mentioning at this point that most people use the same password for everything. Do yourself a favour and search for your favourite password in your email, you might just be unpleasantly surprised.

If you’re the type of person who doesn’t do this and knows better, this article isn’t for you. It’s actually not for anybody, I’m trying to stretch other parts of my brain by writing… So if you’re about to adjust your fedora, stroke your neckbeard and comment to tell us why everybody is a dumbass, why don’t you go write your own article instead?

The largest companies in the world have had their services compromised, so no company is special. This is a good time to recommend that you head over to to check if your email has been previously pwned in any documented breech.

Anyway, the point of the post isn’t to explain why having your login credentials compromised could be a bad thing. I’ll leave that to your imagination…

But Brett, I hear you saying, businesses still need to send their clients a password so they can authenticate? If email isn’t secure, what are they supposed to use to send the clients their password? If you have a better way to do it, then just get on with it and tell us?

I will! They don’t send a password. In fact, they shouldn’t even store passwords in a way that they can access the original at all.

Story time!

A company sends you a mail containing your password or even a password they’ve generated. What does receiving the password in an email tell us about their IT systems?
It highlights that they’re storing the data in such a way that it’s retrievable. That means there is a large bucket with passwords on a server somewhere that somebody has access to.

Don’t worry, the database is encrypted!

So what? I rebut… Even if the mechanism is encrypted, there exists a way to generate an email containing the password. The passwords are available to somebody somehow and that means they can be compromised. That system is inherently insecure by design. If you have access to the user’s password, it can still be leaked, no matter how careful you are.

The only way the password can be properly secure is if the business themselves can’t read it at all! There is no liability if it isn’t possible to access the password. This is accomplished by storing the password in a format where it can’t be reversed into the original text.

But Brett, if they can’t read the password then how are they going to validate the password when you try login? They need that data, there isn’t really any way around that, is there?

They don’t need to know your password, nor do they need to be able to decrypt your password, to validate that it’s correct.

Time for some technical stuff;

I think this process should be used instead of sending the password via an email:

  • User signup process creates a new account that isn’t active by default.
  • Send user an email with a URL to a managed server-side process to activate the account and create a password.
  • Link containing a uniquely generated token that can either only be accessed once or expires in a very short period of time (less than 15 minutes).
  • Connection to this process must be secure using HTTPS (SSL/TLS) (duh…)
  • User enters password of their own creation into process (don’t auto-generate passwords!)
  • The user defined password is randomly salted and hashed using a one-way algorithm.
  • The resultant hash and the random salt are then stored for later verification

TLS, Hashing, Salting? You said not much technical detail!? (Wikipedia links for people who care to do the research)

These terms briefly explained in one paragraph.

TLS: Transport layer security, means the connection from a client to a host is encrypted.
Hashing: Transformation of a series of characters into a smaller key. The same input always generates the same hash. There are multiple hashing algorithms all with their pros and cons.
Salting: It’s the act of adding another random value (the salt) to the original key value (the password) so that when you hash the same password with two different salts, the hash results are different.

Salting and hashing is a one-way process. You can’t infer the original password from the hash, which means that even if their data is compromised the attacker won’t have access to the password.

This means that the login process would now work as follows:

User accesses a login process over a secure connection.
Password is sent to server, where it is salted with the previously generated random salt, and hashed with the chosen algorithm. The resultant hash is compared to the stored hash and viola… validation.

Moral of the story. You don’t store passwords so that when you’re compromised your passwords aren’t leaked.

A few more technical people will say this article isn’t complete and the mechanism mentioned above isn’t actually secure yet… and they’re right! If the data gets leaked and the attackers have access to both the hashes and the original salt values, they can brute force the passwords over time to crack them. Ways to make the system more secure to get around that are beyond the scope of this post. If you’re looking to this post for any architectural guidance, you really really shouldn’t be… I would suggest reading up elsewhere.

Securely creating accounts, storing passwords and authentication is only one small part of keeping a system secure too.

Posted in GeekLevel4, Security | Tagged , , , | Leave a comment

Conway’s Game of Life

The Game of Life is a cellular automaton devised by the British mathematician John Horton Conway in 1970. It crossed my mind a couple of months ago so I wrote a quick and dirty implementation in C# one evening. It’s interesting because it has the power of a universal Turing machine which means that The Game of Life is theoretically as powerful as any computer with unlimited memory and no time constraints. Essentially anything that can be computed algorithmically can be computed within Conway’s Game of Life. It’s also quite mesmerizing.

Rules (ripped straight from Wikipedia)

The universe of the Game of Life is a two-dimensional grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbors, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

  • Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  • Any live cell with two or three live neighbours lives on to the next generation.
  • Any live cell with more than three live neighbours dies, as if by overcrowding.
  • Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Screencast showing simple interactions causing complex results

Code available (C# project VS 2012 Express) through Github if you want to screw around with it.

Posted in Code | Leave a comment

I got a Raspberry PI

It arrived about a week ago. I’ve only found time to mess with it this past weekend and this is a basic overview of what I’ve managed to do so far.



I started with the Debian Squeeze distro image as I’ve got some experience with Ubuntu. I used the Win32 Disk Imager linked on the Raspberry PI site

This utility provides the ability to both read and write images which is incredibly useful as the read function allows you to backup your current image before you attempt anything dangerous.

It booted without issue and picked up an IP via DHCP so I was online on the first try.

Remote access

The next thing I did was enable the SSH server as it’s much easier to work with a remote shell rather than switching monitor input and using another keyboard. I used Putty as the windows client as I’m sure everybody else on the planet does too.

Great tutorial.

Next thing was setting up VNC; another great tutorial below. TightVNC is my windows client of choice.

I’m impressed with the responsiveness over VNC. I expected it to be a little sluggish but the image was clear and the cursor responsive, I even got distracted for a while playing with Scratch. I managed to accidentally programmed a cartoon cat to somersault and fall on its face which was entertaining :)


The Debian Squeeze image is preformatted to 2GB, most likely to cater for the lowest common denominator. I resized the image to use all 8GB with the tutorial linked below after using the Win32 Disk Imager to backup my remotely accessible image first. The tutorial video in the link is excellent and easy to follow.


I bought the Raspberry PI with the grand plan of building a video based hardware hack using stuff I’ve got laying around (watch this space…) so I was disappointed to find that UCV was supported off the bat in Squeeze image provided.

Firmware update

After a bit of googling I found somebody in the same boat as me and it turns out that this is a firmware update that enables Video4Linux.

Make sure you follow the tutorial exactly, performing the rpi-update twice with an ldconfig in-between is required.

Worked a treat and my webcam (Logitech C300) showed up. (using dmesg)

[ 135.398018] Linux video capture interface: v2.00
[ 135.428583] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0805)
[ 135.469825] input: UVC Camera (046d:0805) as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
[ 135.473582] usbcore: registered new interface driver uvcvideo
[ 135.473632] USB Video Class driver (1.1.1)
[ 135.901588] usbcore: registered new interface driver snd-usb-audio

It worked using uvccapture and I was able to product this shocking (or arty) saturated image of my dark smoky mancave.

Posted in Raspberry PI | Tagged , | 1 Response