My first foray into AngularJS

I’ve been aware of AngularJS for some time, a talk by Craig Norton at Agile Yorkshire peaked my interest but I’m ashamed to say that I’ve never invested the time to look into it. A few comments colleagues and blogs have made about breaking changes in V2 have put me off somewhat, is Angular turning into another Silverlight?

We’ve been developing an in house DevPortal at work and a colleague of mine was very keen to use Angular and Bootstrap to investigate their value in bringing into our core product.

Over the past few weeks I’ve been feeling somewhat left behind, unable to contribute to some exciting process changes because I wasn’t up to speed with the technology. Not being familiar (or particularly liking) my lack of understanding and knowing how it feels to be the only evangelist on a team I’ve invested a little time this weekend to try and understand the basics of Angular.

With the help of PluralSight I’ve started covering the basics, I’m not very far through yet but can already remember what intrigued me at Craig’s talk. This is HTML and Javascript, but built in a powerful framework you’d expect from a .NET application.

This is the Hello World of AngularJS, we create a module and a controller and bind the value of the helloMessage to the variable defined in $scope.

<!doctype html>
<html ng-app="app">
<h1 ng-controller="HelloWorldCtrl">{{helloMessage}}</h1>
<script src=""></script>
    <script type="text/javascript">
      angular.module('app', []).controller('HelloWorldCtrl', function ($scope) {
$scope.helloMessage = "Hello World";

I’m looking forward to seeing what’s in the second module!

Multiple Binding Attributes in SpecFlow

I recently discovered something rather nice in SpecFlow, I was implementing a scenario like this

Scenario: Save a user
Given I have a user with the name Joe Bloggs
When I save them
Then the user should have a FirstName Joe
And the user should have a LastName of Bloggs

I wanted to provide the flexibility in the assertions so our QA could decide how he wanted to phrase the text in the scenario. Logically however we’d want the same binding for each variation.

Here’s what I came up with:

[Then(@"the user should have a (.*) (.*)")]
[Then(@"the user should have a (.*) of (.*)")]
public void ThenTheUserShouldHaveA(string field, string value)
  var user = GetUser();
  Assert.AreEqual(user.Properties[field], value);

However this didn’t work, I kept getting a field of “FirstName of”. I discovered however that you can reverse the binding attributes to give priority.

Updating the attributes to

[Then(@"the user should have a (.*) of (.*)")]
[Then(@"the user should have a (.*) (.*)")]

This change gave the of binding precedence and ensured that both scenario steps worked correctly.

Hello Kitty

It seems like a weekly occourance nowadays, whenever you turn on the news or open a technical blog you’re faced with another story where a huge organisation has been hacked and personal information has been stolen.

This time it is Hello Kitty who have lost their members’ personal information. According to more than 3.3 million user accounts have been breached. Unfortunately this is not uncommon, over the last few years we’ve heard similar stories from Sony, Ashley Madison and Experian.

What strikes me time and time again when I read these articles is how poorly my personal information is protected. Let’s look at the Hello Kitty story, tells us that users passwords were hashed with SHA1 but not salted.

Any computer science graduate or junior developer should be able to tell you that this is insufficient! I consider myself a geek so I’m always interested by this sort of thing. Let’s spend a minute to work out what’s going on…

A hash is basically a repeatable one way encryption algorithm. If you use SHA1 to hash a piece of text (such as a password) it’s trivial to repeat but (almost) mathematically impossible to work out the original string from the hashed value. This is great for developers, I save the hashed value in my database and when you enter your password I simply hash the value you gave me and see if it matches my saved version. Neither you, me or any hacker can work out what your password is even if they have somehow stolen my entire database (which I’m also protecting between DMZs, firewalls and physical security).

At first glance the security used at Hello Kitty should have been enough. Because the hackers who stole the data can’t dehash the passwords they can’t use them to log in, try them on other sites (such as your email account) you’d think this information has limited value.

This is where there’s a gaping flaw in the security and unfortunately it’s down to the users of the site. Any hacker worth their salt (pun intended) knows the most commonly used passwords. Which means I don’t need to know your password, all I need to do is hash “123456” and see which of the 3.3 million users used it. Next I try “password”, then “12345”. You won’t match everyone, but how many of these 3.3 million will use one of the top 100 most common? The top million?

So what’s the solution? We use a salt. This is what Hello Kitty should have done, a salt is a random piece of data which is appended to the password. This is often a piece of random text unique to the user which is concatenated onto the user’s password before the hashing process. This time, even if the hacker has access to the salts their lookup table of common passwords is rendered useless. They would need to calculate the top passwords with the salt for each member, a this is a hugely expensive operation and we’re back to brute force. 

Some of the most recent algorithms involve hashing a password multiple times. The effort for us to hash the hash of a password a few hundred or thousand is negligible but our hacker? They’ll have to calculate the hash of every password they want to try, for each member individually multiplied by the number of times you iterate!

I don’t want to go any further into the technical side. What I take you to take away is that somewhere, someone made a decision at Hello Kitty that a basic SHA1 hash was sufficient. That’s not only a huge error of judgement but it has ultimately left their clients feeling vulnerable as passwords are distributed across the web and has destroyed their investor confidence as the company’s reputation is dragged through the mud. Don’t let this happen to your company, don’t let this happen to your users!

Here’s my message.

  • If you’re a developer and you are not confident in your system’s security, don’t be afraid of looking foolish. Raise the questions.
  • If you are a manager who’s reportee raises a security concern, take it seriously. Your entire teams’ livelihood and clients’ confidence is at risk.
  • If you’re an Internet user, look at the common passwords list and avoid them like the plague. Use strong passwords and don’t repeat them across sites. If you don’t feel confident, don’t hand over your personal information!