The Best Password Database – Your Mind

In the wake of Heartbleed, one particularly interesting side effect kept surfacing: users of Lastpass were encouraged to regenerate all “important” (read: All) passwords. 1Password, on the other hand, announced that they weren’t affected. I think it’s great that these password security options are promoting good practices. That said, OpenSSL’s bug today is Agile’s bug tomorrow. It’s still software, and it’s inevitable for it to become vulnerable someday.

The Solution

I don’t remember where I first heard about the first version of this trick, but it’s possible to make human-memorable, secure passwords from the website or app in question. Taking that one step further, if we build those passwords from a set of easy-to-remember building blocks, we can even write those passwords down!

Here’s how it works. Let’s say we want to make a new password for Facebook (which, according to this great tool, is “either fixed or unaffected”). Since this is the first password we’re making, we’ll first need some building blocks. Let’s make a building block called name. Instead of just being the name, “Facebook”, let’s make it the name reversed, “koobecaf”. To add to that, let’s make a second building block, salt, that’s a constant group of letters: “heartbleed”.

The names of the building blocks can be written down, though their meaning remains secret. In our Password List, then, we’d write:

Facebook = name + salt

Anyone could read that, and never guess the actual password. Not only do they not know what to do with name, but they don’t know what the salt is. Even if they attempted to break the password by brute force, the password is 18 characters long, which is great. According to this tool by Dropbox, the password would take “centuries” to crack. That’s secure enough for me.


  • Always use at least two building blocks per password.
  • Never use the websites name exactly. Change it somehow. Take only the first six letters, reverse it, translate it into French. Just don’t use the site’s name by itself.
  • Have as few building blocks as possible, since they’re what you actually have to remember.
  • Store your passwords someplace easily accessible. Even though it’s always a bad idea to write passwords down, you’re not writing down the password, just the building blocks needed to figure it out. So write them down on Post-its, put them in a notebook, store them in your Notes app on your phone, whatever it takes.
  • A “salt” like I showed above is highly recommended. They’re easy to remember, and they can add a lot of security to a password.
  • Some websites don’t allow long passwords. In that case, you’ll have to use shorter building blocks.
  • Feel free to throw in other operators for those blocks, too. For example, one of my pre-Heartbleed passwords was ALG + ALT_SALT / 2. That means it was the ALG block, then the first half of the ALT_SALT block.


Here is a sample of my actual password list, albeit pre-Heartbleed. It only uses three building blocks over seven passwords. (The whole list has seven building blocks, half of which are one-offs for weird password restrictions, over 48 passwords.)

BattleNet: ALG + ALT_SALT / 2
Coursera: ALG + SALT
DigitalOcean: ALG + SALT
Evernote: ALG + ALT_SALT
Evolve: ALG
Facebook: ALG + SALT

My “Annual” Snowman, 2014 Edition

Me and My Snowman 2014

My “Annual” Snowman, 2014 Edition.

This is my “annual” snowman for 2014. He’s about 7 feet tall; I’m slightly in front of him. His arms are a bit hard to see, but one goes out to his walking stick, and the other is raised to his left, waving to the passing cars.

Wipe that snow off your shoulder, Mr. Snowman.

Anatomy of a Schoon TODO

In its original Dutch, my nickname, Schoon, means “clean”. Doubly-appropriate, perhaps, that my method of TODO comments be called a “Schoon TODO” by former colleagues. It’s the cleanest I’ve seen.

Quick disclaimer, perhaps: I don’t know this style to be unique, but I don’t know it not to be unique. I’ve never verified either way, so I won’t assert either to be true. Just take this as “the way I do things, and maybe that’s helpful.”

Here’s a sample, simple, real-world pair of TODO comments in code I just wrote (and which prompted this post):

  // TODO(schoon) - Validation.
  // TODO(schoon) - Ensure the appId (at the least) is unique?

To break this down, there are seven important components to these comments:

  1. Indentation – Make sure your comments are aligned with the surrounding code.
  2. Single-line comment – Please, no blocks.
  3. TODO – Not FIXME, not HACK. At best, these mean different things. At worst, these confuse people. For example, I use HACK to indicate something that needs to change without indicating how, and I never use FIXME.
  4. Your name – It should be apparent who can solve this problem, but don’t make us grep the git log to find it was your idea. Own your TODOs.
  5. Punctuation – Whether it’s a dash or not, make it consistent and put some breathing room in your comment.
  6. Details – The most important part of the comment along with the rest of the comment. Provide enough detail to remind yourself what needs to be done: no more, no less. If there are a lot of details, use your bug tracking software. TODOs are for little, immediate notes.
  7. Punctuation – This is almost the most important little detail. A period indicates this is a concrete, sure TODO. A question mark indicates you’re unsure, and more thoughts and discussions should follow.

I wrote both of these in a two-space-indented block of code, and I’m unsure if or how appId needs to be unique. It needs to be properly-formatted as an appId, however, so that validation needs to happen. But that’s enough analysis – go forth and make your TODOs more useful.

Overwhelming Uncertainty


On a completely different track from my thoughts on Insufficient Uncertainty, today I’m fighting off Overwhelming Uncertainty. Michael Lopp, a.k.a. Rands, introduced me to the concept of “entropy surfing” through his Trickle Theory post. The post is worth a full read, but here’s the ending from this well-written analysis of software development:

Fact is, your world is changing faster than you’ll ever be able to keep up with and you can view that fact from two different perspectives:

1) I believe I can control my world and through an aggressive campaign of task management, personal goals, and a CAN DO attitude, I will succeed in doing the impossible. Go me!


2) I know there is no controlling the world, but I will fluidly surf the entropy by constantly changing myself.

Surfing entropy takes confidence. This isn’t Tony Robbins confidence, this is a personal confidence you earn by constantly adapting yourself to the impossible.

How different is that feeling from dealing with a serious illness? Granted, a trip to the ER ending in a prescription and a generic diagnosis are nothing compared to, say, cancer. That said, both of those people and more suffer from the same, shared, additional problem: Overwhelming Uncertainty.

More troublesome, perhaps, than the diagnosis or treatments themselves is the intimate understanding that we know very little about how well our body is doing at any given time. Only once sufficient data and observation takes place do we learn anything about it, and when we do – our world changes. Fast.

We’re left with those same two options: foolishly attempt to control the chaos, or confidently surf the entropy.

Personally, if only for a lack of fortitude on my own, my confidence comes from faith. And there are days when I’m securely on my feet, on the board, surfing with the best. Then there’s today, and I’m tossed in the waves. I’ll get back on the board, though, and I pray that when your world changes, you’ll have the confidence to join me on the surf.

Remote Meeting Courtesies

With an increasing prevalence of meetings done over Skype, Hangouts, and similar, I feel that everyone (especially remote workers, but this isn’t specific to folks who primarily work remotely) should know a few basic courtesies involved with this young form of interaction.

In decreasing order of importance:

  1. Mute yourself unless you are speaking. – I know you’re being silent while on the call, and that’s fantastic. The problem is that your computer is picking up the faintest sounds, amplifying them, and sending them to the server anyway. Unless you’re actually trying to speak to the group, use the mute feature of the software. This always reduces the background noise of the call, even if you’re not making any.
  2. Don’t interrupt. – While this may seem like an obvious carry-over from in-person meetings, it’s far nastier over these VOIP services. In-person it’s pretty straightforward to interject and add to a teammates comment, as more nuanced communication such as body language can come to your aid and broadcast your intent. When all you’re left with is your voice (often, the primary video being displayed is the person speaking, so video doesn’t cut it outside of the accompanying voice), it’s extremely difficult to cleanly add to another’s statement without creating noise and frustration. You’re statement is still valid and wanted, but the noisiness of interrupting mid-sentence is not.
  3. Pause often while speaking to let others interject. – Because it’s such a noisy ordeal to interrupt someone while speaking, you should pause between ideas. That way, anyone else wishing to speak can interject and add their own two cents. Going back to the lack of body language, you should treat VOIP meetings as miniature speaking engagements, and the same advice applies: pausing allows the other folks in the meeting time to digest your salient arguments. If Bob abuses his ability to interrupt, most VOIP systems allow you to mute others…
  4. Use the chat for out-of-band conversations. – Continuing the trend of not interrupting, if you have a sufficiently-small or unrelated point to add, consider using the built-in chat feature. A separate, minor discussion can occur and be resolved in the chat while the major discussion occurs over VOIP.
  5. Avoid using chat. – It should go without saying, but abusing the chat feature is distracting and rude. Any time and energy spent in chat is detracting from the person speaking, and is unfair to both that person and their ideas.

The first point is by far the biggest and most important, so I’ll reiterate: Mute yourself any time you’re not addressing the group! Following that rule alone will vastly improve meeting online.

That, or you could just hold meetings like this:

Insufficient Uncertainty

I’ve started working on a game with simultaneously-executed turns. It’s meant to be as simple as possible: the first version only allowed for two decisions per turn with only four choices per decision.

Any time you iterate on a concept, you need to know where to iterate and why you’re iterating there. Do it scientifically: build a theory, make a related change, make a measurement, and check your theory. This game wasn’t fun at first (just reading the sentence above might  make that obvious), so I needed to iterate. Time for that theory.

Beware: Academic Material Ahead

Assertion 1: Games are all about stringing together player choice in pursuit of some narrative. My problem wasn’t narrative, as I hadn’t even gotten that far. Instead, it was a problem with choice, so let’s dig in there.

Assertion 2: These Choices are the process of selecting a Desired Outcome from the set of Possibilities followed by selecting a set of Inputs within the game’s systems in an attempt to bring about that Outcome.

In chess, a game of skill, this is simple: the Possibilities are all legal moves and series thereof, the Outcome is a move or set of moves you want to perform, and the Input becomes performing one of those moves with one of your pieces. In Yahtzee, however, luck takes over: the Possibilities are all of the potential dice positions and the Outcome may be a specific position (such as a Full House), but the Input is very limited (roll the dice) and may not achieve the desired Outcome. What prevented my game from being fun might have been the lack of interesting Inputs, but my theory is that the limited set of Possibilities was a larger contributor, so I wanted to dig in there.

Last Assertion (3): The realm of Possibilities is a factor of your available Inputs and the Uncertainty of their Actual Outcome. Remember that a player’s decisions involve selecting a set of Inputs for a Desired Outcome out of these Possibilities, but the rules for evaluating these Inputs and the assumptions leading to their selection lend a lot to the Uncertainty. Jackpot: I had a problem with Insufficient Uncertainty.


Taking a step away from the academic (and downright confusing, perhaps), let’s look at what we’ve codified. A player’s decisions are all attempts on trying to achieve something (the Desired Outcome). The available options for those decisions are defined by the game, and the player will pick one or a set of them, like moving a pawn in chess (the Inputs). Since randomness may be involved or his opponent may have a chance to respond, the player might not achieve his goal – something else may happen (the Actual Outcome).

To make a game more interesting, we can make more Inputs. This makes the decision harder, as there are many choices to consider. This simultaneously makes the game less accessible, and is against my original goal of simplicity. On the other hand, we can make the game more Uncertain, increasing either the randomness (unbalancing the game toward luck) or the number of assumptions made (increasing the amount of hidden information).

Theory in hand (so to speak), I’ll be playing with this Uncertainty. I may introduce a die roll to hit, for example, increasing the luck involved. On the other hand, I could introduce a fog of war, requiring a moderator (such as a computer). Your options may be different, but the rule remains the same: increase the Possibilities, and your game’s choices become more interesting. Increase your game’s Uncertainty, and you increase the Possibilities.

Unit Testing over SMB in Visual Studio


Though I’ve recently upgraded computers, my old Drobo is still attached to the old machine, shared through Windows (SMB) with the new machine. I’ve been working on getting [CS-RESP](github) wrapped up in support of a Unity project, and wanted to start testing it.


After reading all the MSDN documentation I could on using the Test Explorer, I could not get the tests load for the life of me. I tried writing the test classes by hand, deleting them and generating a second time, restarting, you name it. Though common error cases were diligently called out on MSDN, my problem was not. Test Explorer remained empty, and I had no way of running my tests. Even Assert.AreEqual(1, 2); was passing…


As it turns out, it was the Drobo itself that was causing the problem. Or, more specifically, it was a problem with VisualStudio refusing to recognize tests within the shared folder. Bizarre. Perhaps more bizarre is the solution. The following environment variable is required:

setx COMPLUS_LoadFromRemoteSources 1

Run that line in Command Prompt, and your problem should be permanently solved.

While I didn’t have the exact error this gentleman had, here’s some more information:

No Brakes Valet

When we couldn’t find anything to play on the 360 and Nidhogg seemed a little too challenging, I broke out the @PlayOuya with my folks. No Brakes Valet was immediately accessible and a lot of fun. It’s shaping up to be a party favorite.

The study and studies of the Schoon(s).