Any opinions expressed here are my own and not necessarily those of my employer (I'm self-employed).

May 15, 2012

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?

May 13, 2012

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:

Copyright notice

© André N. Klingsheim and www.dotnetnoob.com, 2009-2018. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to André N. Klingsheim and www.dotnetnoob.com with appropriate and specific direction to the original content.

Read other popular posts