Tuesday, 26 March 2013

C is for cookie, H is for hacker – understanding HTTP only and Secure cookies

Tuesday, 26 March 2013

Since a very young age, many of us have been taught that C is for cookie and that apparently, “That’s good enough for me”. Except it’s not – the hidden depths of the cookie were never really explored so is it any wonder that after being ingrained with such a trivial view of cookies from such a young age that so many of us are handling them in an insecure fashion?

You see, there’s far more to cookies than meets the eye and I want to delve into a couple of aspects that when configured poorly, can pose serious risks to website security. Most of the time when I see these two problems it’s not by design (and there are valid design use-cases), rather it’s because very frequently, the developer didn’t even know they exist. Think of it as one of those “don’t know what you don’t know” sort of situations.

Anonymous Cookie Monster

In order to help you defend against the Anonymous Cookie Monster, I’m going to explain what an “HTTP only” cookie is and also what it means to use “Secure” cookies. But first, let’s just recap on why we need cookies in the first place and what the potential security ramifications are of getting them wrong.

Read more

Monday, 25 March 2013

Time travelling with dates and time zone conversions in .NET

Monday, 25 March 2013

Here’s a little magic trick in .NET: In ASafaWeb I have a facility to schedule scans at a certain time of day. Because I want to be all warm and fuzzy and user friendly, when people sign up to the service I ask for their time zone then whenever they schedule a scan they enter the time of day they’d like it to happen in their local time and I pull some magic tricks to make it happen.

The process has been working flawlessly since the middle of last year – until this weekend when I started getting error notifications that something was amiss. You see, the magic trick involved taking the time of day in the person’s local time zone, converting it to UTC then storing that in the database. This magic is made possible by using TimeZoneInfo.ConvertTimeToUtc and it works just like this:

var sourceTime = new DateTime(2013, 3, 31, 1, 0, 0);
var sourceTimeZone = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
var utcTime = TimeZoneInfo.ConvertTimeToUtc(sourceTime, sourceTimeZone);

Create a source time, create a source time zone then convert it into UTC. This works perfectly except when it doesn’t and presents you with an ArgumentException like this one:

The supplied DateTime represents an invalid time.  For example, when the clock is adjusted forward, any time in the period that is skipped is invalid.

An invalid time?! Since when is 1am on March 31 an invalid time? I mean it’s not like it’s November 31 or February 29 on a non-leap year, what an earth is wrong with this time?! And for that matter, how on earth do you get an error when converting GMT to UTC, isn’t it the same thing?!

The problem is that 1am on March 31 this year simply will not exist in the time zone above; people there will literally travel through time! The other problem is that GMT isn’t UTC – but it’s close.

Of course the issue is daylight saving and it can ping you both ways. When you wind the clock back you literally experience the same hour of the day twice. Any represented time that falls in that hour is ambiguous as you don’t know whether it was the first occurrence or the second occurrence so it could be anywhere up to an hour wrong. Then we have the problem above where that whole hour simply doesn’t exist which is why TimeZoneInfo won’t let us create it.

But hang on, doesn’t GMT align to UTC and not observe daylight saving anyway? Well firstly, there are semantic differences between the two and secondly, the “GMT Standard Time” you see above is the StandardName attribute of the TimeZoneInfo object the FindSystemTimeZoneById method ultimately returns. Here’s how the other attributes look:

DaylightName: GMT Daylight Time
DisplayName: (UTC) Dublin, Edinburgh, Lisbon, London
SupportsDaylightSavingTime: true

In short, this time zone does observe daylight saving and as you can see here, it’ll roll over at 01:00 on March 31 this year.

So what do you do? Catch the ArgumentException, add an hour an then you’ve got exactly the same time of day as you were originally after. At the time I wrote the code I didn’t consider this eventuality but fortunately the fix was simple and there’s now a nice little unit test to make sure I don’t screw it up again. Conditions like this are literally a 1 in 61,362 occurrence and in the scheme of things, ASafaWeb is a small app so this was really needle-in-a-haystack sort of stuff. We all know the mechanics of daylight saying insofar as clocks going forward and backwards and it’s something I should have gotten right the first time.

Oh, and in case you’re wondering, if you try converting 01:30 on October 27 when the UK goes out of daylight saving this year to UTC you’ll get… 01:30. You just don’t know whether it was the first one or the second one! For more enthralling time zone reading, check out Jon Skeet’s More fun with DateTime.


Thursday, 21 March 2013

Are we ready to do our banking via Facebook?

Thursday, 21 March 2013

Browsing through my Facebooks the other day, I came across an interesting little sponsored ad:

CommBank Kachine advert on Facebook

Banking, you say? In your Facebook, you say? What could possibly go wrong?!

The overriding concern that immediately sprung to mind was that you’re mixing two domains of a very, very different nature. On the one hand we have our social media, frequently the source of status updates about our breakfast, commentary on the latest lolcats and as I’ve written on numerous occasions before, favoured channel of scammers. On the other hand we have our financial well-being, records of our earnings and a domain which we generally expect to hold to the highest possible standards of security.

Of course there is also intersection: sometimes our social network intersects with our financial network and indeed CommBank frequently draws attention to the ability to pay friends in their promo material. But does the intersection of these two polar opposite domains pose entirely new risks to online banking? Will the higher prevalence of security risks in social network undermine our banking security? Let’s take a look.

Read more

Tuesday, 5 March 2013

Should websites be required to publicly disclose their password storage strategy?

Tuesday, 5 March 2013

I don’t know how Evernote stored my password, you know, the one they think might have been accessed by masked assassins (or the digital equivalent thereof). I mean I know that their measures are robust but then again, so were Tesco’s and according to their definition, “robust” means storing them in plain text behind a website riddled with XSS and SQL injection (among other security faux pas).

Last year we saw LinkedIn breached and some millions of SHA1 passwords with no salt exposed. Last week we saw Australia’s own ABC do the same thing; it took me 45 seconds to crack 53% of those and others have since gone on to crack more than 90% of them. These storage mechanisms are not robust, they’re stupid. The problem, of course, is that consumers don’t know a website’s password approach is stupid until after they’ve entrusted their passwords with the site. That is a fundamental problem.

I propose that websites should be required to disclose their password storage mechanism. The disclosure would sit right next to the point where the password is provided for persistent storage, namely on the registration and password change pages. It would be as simple as this:

Password storage statement: PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations

Let me explain the thinking.

Read more