How not to hash passwords in .NET

In connection with a bug in TransformTool, I've been looking into how text encoding is handled in the .NET framework. Turns out there are some caveats that can affect the correctness of a program, and when used in e.g. password validation they might turn out to be severe security issues.

This post assumes you are somewhat familiar with how character encodings work. You might want to check out my Introduction to character encoding if you're not. I wrote it mainly because I didn't want to explain the basics of encodings in this post.

The encoding issues/features I discuss here are all well documented in the article Character Encoding in the .NET Framework, but I believe that the issues aren't that well known. Stack overflow, blogs, and discussion forums are riddled with insecure code samples. Do a Google search for "ASCII.GetBytes" password, and you'll get a lot of results. I even found insecure code examples in a text book, the C# 2008 Programmer's Reference (page 344). So I definitely believe we need to raise awareness of these issues in the .NET community.

Encoding subtleties
In the MSDN article on character encoding you'll find that the first suggestion on how to use the encoding objects in .NET is: 

Use the static properties of the Encoding class, which return objects that represent the standard character encodings available in the .NET Framework (ASCII, UTF-7, UTF-8, UTF-16, and UTF-32). For example, the Encoding.Unicode property returns a UnicodeEncoding object. Each object uses replacement fallback to handle strings that it cannot encode and bytes that it cannot decode.

And people love to use the static properties! But if you don't read this carefully and pause with the "replacement fallback", you might get into trouble. "Replacement fallback" means that every character that cannot be encoded to bytes will be replaced with the "?" character silently. But what does that mean? Time for a demo using the ASCII encoding:

Introduction to character encoding

"FACE WITH TEARS OF JOY" (U+1F602)

Text encoding is a persistent source of pain and problems, especially when you need to communicate textual information across different systems. Every time you read or create an xml-file, a text file, a web page, or an e-mail, the text is encoded in some way. If the encoding is messed up along the way, the receiver will be looking at strange characters instead of the ori�inal t□xt. (ba-da-bing :)

I've been fighting with characters sets on several occasions throughout the years. Just recently, I had a bug in TransformTool related to character encoding and how errors are handled in the .NET framework. While writing about the bug I needed a reference to a basic introduction to character encoding — only to discover that most are very technically focused and dive right into the characters' hex codes. Here, I'll try to fill that gap and explain only the basics. I'll include pointers to more detailed resources in case you decide to dig deeper into the dark world of character encodings.

How encodings work
The Unicode Consortium has a great explanation of how it really works:

Fundamentally, computers just deal with numbers. They store letters and other characters by assigning a number for each one.

IE auto-upgrades, plugins next?

Last week the IE team announced that they'll soon start to automatically upgrade IE across Windows 7, XP, and Vista through Windows Update. A follow up from Microsoft's IT pro team details that IE 6 and IE 7 will be upgraded to IE 8 on Windows XP, while Vista and Windows 7 users will get IE 9. With Microsoft joining the herd of auto-upgraders the final pieces of the puzzle start to fall into place, now "everybody" does it. Other major browser manufacturers (Opera, Chrome, and Firefox) have been auto-upgrading their installations for some time already. Apple's Safari now stands out in the crowd and it will be interesting to see whether they'll stick to their current update regime.

For Microsoft, this is yet another important step to kill of IE 6 which still has a considerable user base. Up til now they have been running campaigns urging users to upgrade their browsers. They actually have a website dedicated to kill of the browser, www.ie6countdown.com (I have to point out that Norway is leading the pack, with only 0.2% IE 6 users). Hopefully the automatic upgrades will have a notable impact on the remaining IE 6 installations.

In two earlier posts (one and two) I've advocated silent auto-upgrades as an important strategy to keep Internet users safe by providing them with timely security patches. Recently I came across an interesting study on the effectiveness of different Web browsers update mechanisms. It's definitely worth a read. (*Surprise*, it aligns just fine with my views so I can safely link to it).

See pics of women, free

Just now on Facebook I got the following advertisement:

I didn't quite react at the first glance, since every once in a while you get served the ads for "Russian ladies looking for love" etc. (hope I'm not the only one getting those). Then I realized that this ad was for Match.com! That's amazing. I clicked on it, and yes, it led me to: no.match.com.

The title of the ad suggests that it leads to one of the more sleazy sites on the Internet. If you do a Google search for free pics of women, you'll get the idea. Warning: NSFW!

I'm not convinced that this is how girls looking for a relationship would want their profiles advertised on the Internet. And it is yet an example of how a social website might try to capitalize on the personal information you've shared — in a way that would make you uncomfortable if you were made aware about it.

Shame on you Match.com! This is not how a responsible and respectable dating site would treat their users.

Twitter app privacy, there just might be hope!

A couple of months ago I blogged about Giving up your privacy for nothing at Yahoo News, ranting about how the Tweet button on a Yahoo News article required you to give complete control of  your Twitter account to some Twitter application. Well, I just had a more encouraging experience!

You've probably heard about this Klout thing. On Twitter there has lately been several reports of people getting Klout perks, so I became a bit curious on how all of this worked. After all, there's not that many web pages where you sign up and then get stuff sent to you by mail because you have many Twitter followers (deliberate over-simplification). I had to register to see what this thing was all about.

Note that there is an ongoing privacy discussion about Klout, here's an excellent article that summarizes some of the issues. I won't go in to that discussion here.

You can sign in to Klout using your Twitter profile. An this is where I was in for a pleasant surprise!

Base64 decode online — are you sure?

Are you using one of the many web pages that let you base64 decode data? In that case you should take a moment to think about the nature of the data you want to decode and what those pages could be doing with the data — apart from showing you the decoded version.

tl;dr: Check out transformtool.codeplex.com for an offline alternative to the online Base64 decoders.

Google's keyword tool reports 9,900 monthly searches for "base64 decode online". How many of these searches lead to disclosure of sensitive business information, or personal information (PII) to one of the Base64 decoding webpages? None of these searches are from IT-professionals trying to figure out what's wrong in a production system, right?

Top Google results for "base64 decode online" at time of writing

Update Java — or just remove it

Oracle recently released an update to its Java software, fixing more than 20 critical security issues in the software. Krebs has a good post on the update, briefly discussing the vulnerabilities and the fact that Java vulnerabilities are exploited for real.

I have to say that in recent years I've installed Java more due to habit than because of an actual need for the software. So when I got the update bubble in the corner of my screen, I figured "of course". I knew they, among other things,  fixed the same-origin-policy bypass used in the BEAST attack (You'll find a straight forward explanation of the Java vulnerability here, and links to resources on BEAST here). So I started the update process, and this was one of the first screens I was presented.