Outlook.com, custom domains, and ActiveSync

Microsoft's widely used e-mail service Hotmail was recently overhauled and rebranded Outlook.com. One of the less known services they provide is the support for custom domains. A couple of months ago, I was looking for a new (preferably free) e-mail service for my personal domain. It turned out Outlook.com had everything I needed!

To set up a custom domain, you'll first have to log in to the Windows Live Admin Center with your Microsoft account (I used my good ol' Hotmail account). There you'll add your custom domain, and you'll get instructions on how to set up DNS etc. You can choose between closed membership, i.e. you'll register the e-mail accounts yourself, or open membership which lets users register e-mail accounts under your domain themselves. The setup was straightforward, so I won't repeat the steps here. You initially get a limit of 50 e-mail accounts for your custom domain.

Some important ASP.NET 4.5 security improvements

The .NET 4.5 framework was released a couple of months ago and it included several improvements in the security area. To benefit from these improvements you need to do a few changes to you application's configuration file. The documentation is a bit scattered over MSDN and MSFT blogs, I figured I'd collect them here for easy reference.

The ASP.NET team published a nice article on What's New in ASP.NET 4.5 and Visual Studio 2012. There you'll learn that:

• There are changes to the ASP.NET request validation, it now supports deferred (lazy) validation, as well as giving the option to fetch data unvalidated.
• The AntiXSS library is included in the framework.

However, there's no mention of two other important changes:

• There are significant Cryptographic Improvements in ASP.NET 4.5. Read it! This is important stuff!
• Windows Identity Foundation is now included in the framework, referred to as WIF 4.5.

To take advantage of these new bits you'll have to do a bit of configuration, we'll get into that right away.

How to encrypt a custom configuration section in ASP.NET

Recently I wrote a piece of software that needed some configurable secrets — and they needed to be VERY secret. Consequently, I had to encrypt a custom configuration section. Unfortunately, I quickly ran into trouble and got an error message along the lines of:

Encrypting configuration section...
An error occurred creating the configuration section handler for myConfigSection: Could not load file or assembly 'MyAssembly, Version=2.0.0.0, Culture=neutral' or one of its dependencies. The system cannot find the file specified.
...
Failed!

Disheartening, eh? I looked to the Internet and the advice seemed to be to copy the "missing" assembly to the .NET framework folder. I strongly suggest you don't do that, messing around in the framework's folder is not recommended. That folder belongs to Microsoft.

Fortunately I found a much easier workaround. I'll give an example where I encrypt the configuration section for the NWebsec security library, in the DemoSiteWebForms project that's part of the project's solution.

Security through HTTP response headers

Security headers in an HTTP response

There are many things to consider when securing a web application but a definite "quick win" is to start taking advantage of the security HTTP response headers that are supported in most modern browser. It doesn't matter which development platform you use to build your application, these headers will make a notable difference for the security of your website anyway!

The screenshot shows what the security headers look like. The security headers are included in the web server's response to a browser — instructing the browser to enable (or disable) certain security features. They're invisible to the user, but you can have look at them with tools such as Fiddler or the developer tools that are built into the major browsers. In IE or Chrome press F12, in Opera (Ctrl+Shift+i), in Firefox (Ctrl+Shift+k), for Safari have a look here to enable the developer tools.

A great thing about these response headers is that they're very easy to get started with. In many cases you might not even have to change a single line of code in your application as you can set the headers either through your application's configuration, or they can likely be set by whatever web server you use.

If you're building ASP.NET applications I would like to point you to NWebsec, an ASP.NET security library that lets you easily configure these headers for your application. Go and have a look at the documentation, it explains how you can configure the headers through web.config. Don't worry, if you're the MVC kind of person you can use filter attributes instead. You'll find the library on NuGet so you'll be up and running in a matter of minutes! Disclaimer: I built it, so I think it's pretty cool.

A quick note: Last year, I gave a lightning talk at the ROOTs conference about the role browsers play for your online security. There I also discussed security headers. Slides and video are online if you want to check them out: "The browser - your best friend and worst enemy" (slides / video).

Now let's have a look at the headers and how they can improve the security of your website.

Generating secure Guids

Guids are used extensively throughout Microsoft systems and developers tend to turn to Guid.NewGuid() whenever they need to create a value to uniquely identify something. Guids might also be used as keys or identifiers in security critical operations — under the assumption that they are hard to guess for an attacker. I've been looking around the Internet to see if I could find some guidance on Guid security along with details on how they are generated in the .NET framework. I couldn't find much information, but I did find that Eric Lippert from the C# team recently raised some concerns about the Guids on his blog. So I started digging around to see what more I could find out.

First of all a quick background. Microsoft's Guid is their implementation of the Universally Unique IDentifier (UUID) outlined in RFC 4122. UUIDs are 128 bits, and the Guid class generates version 4 UUIDs, meaning that all bits except those defining the version and variant of the UUID are "random." Please note that 4 bits are used for the version number, and two bits are used for the variant — so it's not a 128 bit random number, it's a 122 bit random number.

Towards more secure password hashing in ASP.NET

A couple of weeks ago I was remotely involved in a discussion on password hashing in .NET with @thorsheim, @skradel, and @troyhunt. (Follow them if you're on Twitter). The background for the discussion was that password hashing using MD5/SHA-1/SHA-256 isn't quite the state of the art anymore. All the recent password breaches have triggered recommendations to make password cracking harder. The algorithms that are usually recommended are PBKDF2 (Password based key derivation function), bcrypt, or scrypt. So which of these should you choose if you're working with .NET?

I'm a conservative guy. Cryptographic algorithms are very hard to get right, as there's all sorts of things that can go wrong when you implement them. Consequently, I prefer to use whatever is available in the .NET framework. That's because Microsoft have crypto-experts on staff, and they've also pioneered the SDL which means you should expect high quality implementations of their (security critical) software. So it's really a trust thing. At the time of writing, PBKDF2 is the only algorithm of the three mentioned that's readily available in the framework. You probably see where this is leading: bcrypt and scrypt are disqualified in my book. When it comes to cryptographic functions, stick with the framework! PBKDF2 is the best alternative for now.

Following the discussion on Twitter, @skradel shared a library where he had wrapped the built-in PBKDF2 as a HashAlgorithm. That way, PBKDF2 (through his wrapper) could easily be used by other parts of the framework, such as the SqlMembershipProvider. It really was an elegant solution. He blogged about it in: Strong Password Hashing for ASP.NET, you should check it out (@thorsheim was so delighted that he had to blog about it too :).

When you're dealing with PBKDF2, you'll see that it takes a couple of parameters. @skradel's already chosen some reasonable defaults in his implementation so it's all hidden and taken care of there. But if you were to implement this yourself and explain to someone how you chose those parameters, what then?

How Finnish disco killed my privacy

I noticed some unexpected activity on my Facebook wall the other day. I have a special list of "friends," who aren't really friends but more aquaintances. I have used that list to block them from seing much of what's going on on my Facebook wall (hey, we can still be "friends" right?). Now suddenly some of these people started "Liking" stuff I posted. And that struck me as..... weird.

What was going on? Turns out that I've been sharing my updates with all my "friends" since 31th of March. And I had no idea I was doing that — until I noticed that users I thought to be blocked had started interacting with my content.

After some investigation I found that ever since I shared a "Finnish disco" video on the 31th of March all my posts had been set to be shared with "Friends." That of course includes my blacklisted "friends." At first I couldn't understand how that was possible. I had read about the per post sharing settings when they first showed up, and here's Facebooks privacy policy dated 26th March 2010, explaining really well how it works. And I quote the relevant part:

Posts by Me. You can select a privacy setting for every post you make using the publisher on our site. Whether you are uploading a photo or posting a status update, you can control exactly who can see it at the time you create it. Whenever you share something look for the lock icon. Clicking on the lock will bring up a menu that lets you choose who will be able to see your post. If you decide not to select your setting at the time you post the content, your content will be shared consistent with your Posts by Me privacy setting.

Note that last sentence. If you don't select anything, it will go with your default setting! And my default setting was of course to share with "Friends," except for my blacklist. So what went wrong? Fast forward to today's privacy policy (called the Data User Policy, dated September 23, 2011). And I quote again: