Security Briefs

CardSpace v2 moving into a new role?

2009-05-20T17:41:07Z

In the first version of CardSpace (the one that shipped with Vista), the focus was on building an identity selector that put the user at the center of the transaction. With v2 on the horizon, it feels like the emphasis is changing. No longer do I hear talk about user centricity. Rather now the identity selector seems to be positioned as a user-friendly form of home realm discovery for federated identity scenarios. Indeed CardSpace Geneva doesn’t include support for personal cards at all (although the CardSpace blog indicates that this is coming). The new selector is smaller and quicker to use, and does not ask the user nearly as many questions.

Ruchi Bhargava, a dev lead on the Federated Identity team who currently leads the CardSpace team, has some enlightening comments in a recent screencast. I’ve done my best to transcribe here some interesting tidbits that I found a little more than halfway through the screencast:

“When we built CardSpace v1, our idea of CardSpace v1 was that we are going to have these users who are going to be very worried about security and very interested in identity. What we have realized is that, not really true, most users don't really care about identity, most users just want to get into an application. Really choosing an identity is just a step in getting to the application.

In v1 we had a whole drama around the identity selection experience we had the secure desktop, which would take over the screen which would result in sometimes the user losing context in what they were trying to do…

…the mantra is we are trying to fix three things. We are trying to make our product lighter. We are trying to make our product faster. We are trying to make our product smaller...

...we've realized that we don't really want to be different from existing ways of using credentials and using identities. We actually want to use the same metaphors so that users understand them and are seeing them multiple times. We've tried to use CredUI, and we've gotten rid of a lot of the steps that you had to take to choose an identity. The number of clicks that you have to do are much much fewer now. It's a much faster experience for the user.”

These changes will definitely make CardSpace more attractive to users, although it diverges from the original vision, which was all about getting the user involved in an “introduction ceremony” to help a user decide if she wants to trust a relying party with her personal information. Apparently Microsoft has discovered that users are put off by ceremony and would rather just “get on with using the application”. Regardless of how you feel about this shift, it’s helpful to know that it’s happening.

Are complex federation scenarios driving us away from user-centric identity?

2009-05-19T15:00:36Z

As I pointed out in my last post, in corporate federation scenarios, we don’t need to put the user at the center of the transaction. In these scenarios it’s not her personal information being shared, but rather a corporate identity that’s attached to her because she works for a company, and part of her job includes sharing some of those claims with trusted partner organizations via federation.

But outside of the corporate space, in the sphere of social apps for example, things become less clearcut. For example, let’s say you wanted to build a social application in the cloud that relies on the .NET Access Control Service (ACS) to provide some basic role-based access control features. And let’s say you support some big identity providers like Windows Live ID (WLID), and maybe others that will more than likely come along in the future. Now you’ve got a reasonably complex federation scenario, where WLID (say) authenticates the user, provides claims about the user to ACS, which transforms those claims into something your app can use. How would you put the user in the center? Doesn’t the user need to authorize which claims WLID divulges to ACS? And then further, which claims ACS divulges to the app?

It’s interesting that today WLID doesn’t issue claims from the user’s WLID profile. It’d sure be nice to be able to get the user’s given name and surname, for example. The only claim WLID supports seems to be the user’s ID (the email address she uses to sign-in to WLID). I wonder how WLID will ever support more than that in a federation scenario like I describe here? How would WLID know to trust ACS with the user’s profile info, given that ACS may pass this info to any other app? How does the user know that ACS (or any other intermediate issuer) is trustworthy enough to handle her personal information? While the user probably trusts the application to some extent, it seems ludicrous to ask her if she trusts some intermediary like ACS.

Perhaps this is one of the tensions that helped push CardSpace v2 away from user centricity. But more on that in another post.

Is the Identity Metasystem user centric or not?

2009-05-07T16:04:25Z

My first introduction to this term involved reading Kim Cameron’s article, where he defined it. That article lists seven laws of identity, which make it clear that the user should be at the center whenever identity about her is revealed to a relying party. But over the last couple of years I’ve seen this term used in contexts that have nothing to do with putting the user at the center. Specifically I’m thinking of discussions of federated identity, typically used in a corporate setting, where WS-Federation is used to give members of an organization a single-sign on experience to their own resources and often resources in partner organizations (cross-org federation). In many of these cases, the user isn’t given any notice that her identity is being shared with a relying party. There’s usually no identity selector involved at all, and the user isn’t shown what attributes of her identity are being shared.

Now in a corporate environment, when the user’s attributes are not personal (e.g., her SSN or credit card number isn’t being shared, rather her employee ID, groups that she’s in, etc. are being shared instead), who cares about putting the user at the center? It’s not necessary and would probably just annoy the user by adding an additional step (the user granting permission for these attributes to be shared).

But why do people still use the term, “Identity Metasystem” in this context? Just because we’re sending SAML tokens around using WS-Trust and WS-Fed (passive) doesn’t mean we satisfy the seven laws.

Feed Browser

2009-04-08T20:13:56Z

Today I’m wrapping up an update to the whitepaper for the .NET Access Control Service (ACS) which now includes an AtomPub management interface. I wanted to explore this a bit, and found that browsers didn’t work well since these atom documents have xml content, not HTML content. So I hacked up a little feed browser that lets you navigate the structure of an AtomPub resource.

Feed Browser is a very simple browser – you can type in the URL of an AtomPub resource and it’ll parse the resulting atom feed or entry and display it in two ways: in the left pane it displays a FlowDocument that includes hyperlinks for each <link> element, which allows you to navigate the structure of the resource using only HTTP GET. And in the right pane, it displays the raw XML for the feed or entry. I don’t make any attempt to parse the content of entries, but I found this tool helpful for poking around ACS, and you might find it helpful for looking at other browser-unfriendly AtomPub resources as well.

Here are the bits. I built this project using Visual Studio 2008 SP1.

Enjoy!

Demos for my DevWeek talks

2009-04-01T17:51:46Z

Thanks for those of you who attended my talks last week in London.

The ASP.NET Attack and Defence talk covered SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). The first two have downloadable demos and labs as part of my input validation module series. I don’t yet have any downloadable labs/video for CSRF, but I plan on adding that soon to my ASP.NET Security module for Pluralsight On-Demand. This is a free sample module that we give away to help folks evaluate our online training product.

The all-day workshop on claims-based access and the Geneva Framework resulted in a ton of sample code as well. I’ve uploaded that here.

Enjoy!

Welcome Eric Burke

2009-03-12T15:13:47Z

Eric is one of our newest instructors, and he’s got a new blog on our website.

Here’s what he’s got to say about himself:

“Eric Burke is a member of the technical staff at Pluralsight, where he focuses on WPF and Silverlight. Eric is also a Principal Technical Yahoo! at Yahoo!, Inc., where he is a lead developer on the Yahoo! Messenger team. Since graduating from Purdue in 1994, Eric has been building software applications on Windows platforms. Eric is interested in all aspects of the .NET Framework, but specifically WPF, Silverlight, and other client technologies. He is also particularly interested in figuring out ways to improve performance of end-user .NET client applications. Eric has spoken about WPF numerous times, including at Microsoft and MIX07.

When not cranking out code or squeezing out the last bits of performance on his WPF apps, Eric can be found hanging out with his wife Jenn and their kids, Alexis and Nathan. He also enjoys coaching football, watching football, thinking about football, talking about football, and pretty much anything else that has to do with football. ;)”

Subscribed!

Towards smarter password management (part 2)

2009-02-26T18:04:41Z

Passwords suck. But we're stuck with them for awhile. This little series of articles is my attempt to explore how you can implement a password store and login page that makes the best of it.

A typical web app that has a user name/password store typically has two points of entry for an attacker:

A. The system's internal password store.

B. An anonymously-accessible login page.

In part 1, I shared some thoughts about (A), and this part will focus on (B).

Here are a modest list of goals for a good login page. Do you concur?

Goal 1: Prevent online password-guessing attacks.

This is the biggie. Imagine an attacker running automated dictionary and brute force attacks against your user store from the comfort and safety of his home in (insert name of impossible-to-prosecute-in foreign country) from the hundreds of machines on his personal zombie bot net. I've seen lots of articles that talk about the need to achieve this goal, and some even offer rudimentary suggestions on how it might be done. I'm hoping to take a broader view of the topic and get to a solution that addresses more than just this one goal. And I plan to follow up with code that you can use in your ASP.NET websites.

Goal 2: Prevent information leaks.

Login pages are inherently risky. For some websites, this may be the only page accessible to anonymous users. And a login page provides a direct entry point to a highly valuable resource: your user account store. So you want to be very careful to design your login page so that it doesn't leak information. The most obvious example of unintended information leakage is accidentally validating user names for the bad guy.

User names aren't typically considered secret, but there's no point making it easy for an attacker to collect a list of valid user names at your website. Knowing a valid user name just gives the attacker a target for a password guessing attack, or fodder for a social engineering attack. A simple example of a login page that doesn't meet this goal is one that has a different error message depending on whether the user provided a valid user name or not. Say, invalid user name, as opposed to the more vague invalid user name or password. This fights against usability, but it's a pretty reasonable tradeoff for most sites. A more subtle violation is where an attacker can use a side channel such as timing to determine a valid user name. If (as I discussed in part 1) you are using an iterative hash to validate a password, but you only perform this lengthy computation if the user supplies a valid user name, then the attacker may be able to tell the difference between a good and bad user name by keeping stats on how long it takes for your login page to return a response.

Similarly it would be bad if the page leaked information about the privilege level of a user, because when the website is the target of attack, high privilege user accounts are the juiciest targets.

Goal 3: Prevent client-side capture.

Many browsers offer to remember passwords for the user. I could write an entire article on the plusses and minuses of stored passwords, but I think we all agree that on shared computers (think Internet Cafe) we would rather that the user NOT store her password in the browser. If there's a keylogger on the box, her password is already compromised as soon as she types it, but there's no point inviting attack by leaving stored passwords in the browser as well (one of the evils of passwords is that they have long lifetimes).

Have you ever noticed that some websites don't work so well with browser-stored passwords? It's like the browser doesn't recognize the password field (and often the user name as well). Knowing how to do this seems like it'd be a good tool in your bag of login page tricks.

Goal 4: Do all of this without introducing Denial of Service (DoS) vulnerabilities.

You don't want to end up with a login page that makes it easy for an attacker to prevent legitimate users from logging in.

Goal 5: Do all of this while keeping your login page easy to use for legitimate users.

If your login page is hard to use, your customers will hate you. This is not good from a business or a security standpoint.

Do you agree with the goals I've listed here? Am I missing anything?

Next up, we'll look at some random bits of advice that I've found during my research, and see how they help achieve these goals.

Excellent paper on password recovery

2009-02-26T17:33:49Z

This paper by Charles Miller has been around for awhile (2002), and I only now happened across it while gathering resources for my smarter password management series. A couple of quotes will give you a feel for the practicality and style of the paper, which came out of discussions from the webappsec mailing list at securityfocus.com.

"Some systems allow the user to choose the questions as well. This is a bad idea,
as users don’t understand security, and will either make things too easy for an
attacker to guess, or too hard for themselves to work out what the hell they were
thinking, six months hence."

"If the process is not automated, and for some insane reason you have the original
password on ﬁle, “What did you think the password was?” can be an effective
question."

Towards smarter password management (part 1)

2009-02-21T15:43:38Z

I've been thinking a lot lately about password management. I'm not talking about how a user manages the myriad of passwords she's stuck with, but rather how a system (e.g., a website) should go about accepting, storing, and protecting the password she chooses to use with that system. Face it. Passwords suck. But in reality, we're going to be stuck with them for awhile, and it'd be nice to have some better guidance for people building systems that must manage them.

What motivates an attacker to want to know someone's password?

1. Penetrate that system - by gaining control over a user's account, an attacker gains a foothold, the depth of which is usually dependent on the level of privilege of the compromised account.

2. Glean knowledge about the user's password - this could lead to attacks against other systems where the user has similar passwords.

3. Denial of service.

I'm nervous about storing people's passwords. And you should be too. So my main consideration in this little series of articles is going to focus on (2). Discovering PII can be profitable, and I want to build systems that make this as hard as possible for the bad guys.

There's two avenues of attack at a typical website:

A. The system's internal password store.

B. An anonymously-accessible login page.

The store (A) should be protected so that an attacker cannot read it (2) or modify it (1, 3). And if an attacker does manage to read the store, it would be helpful if the store itself wouldn't immediately divulge its secrets. You can strengthen a password store against offline attack by "salting and stretching" passwords with techniques such as PBKDF2, from PKCS#5. This protection serves to slow down an offline attack, but likely won't prevent him from eventually discovering at least some user passwords. At this point your main protection is the strength of your password policy - if you allow short passwords, or easy-to-guess passwords, it'll not take long for an attacker to discover them. You could go as far as performing your own dictionary attack against a proposed password before accepting it.

You can further strengthen your own website by detecting such a breach and reacting by forcing users to reset their passwords by authenticating using a stronger, less convenient means. But those countermeasures aren't going to matter if the attacker's motivation is (2).

I'd hazard a guess that the vast majority of ASP.NET systems out there that store passwords are using SqlMembershipProvider, which does provide some basic protections like salt, but does not stretch passwords at all. It does provide some rudimentary methods for requiring strong passwords, but certainly doesn't attempt a dictionary attack against them. And the password reset mechanism is very, very weak by default - supply your own question and answer? Don't get me started on that! "What color is the sky?"

So readers, what am I missing in my analysis so far? In my next installment, I'll start focusing on (B), which in truth, is really what I'm interested in at the moment.

Back to basics

2009-02-10T04:36:06Z

I've been getting a bit behind on my blog reading. So the other day, I took it upon myself to read some older posts on some of my favorite blogs. And a couple of items resonated with me enough that I decided to take some action. This recent item from Scott Hanselman lead me to his outline of favorite presenting tips, where he reminded me to update the colors I use in PowerShell.

"I've found that the most readable setup for Command Prompts is a Black Background and with the Foreground Text set to Kermit Green (ala "Green Screen." Yes, I was suspicious and disbelieving also, but believe it or not, it really works.) I set Command Prompts to Lucida Console, 14 to 18pt, Bold as well, with much success."

My shell used to look like this:

...but now it looks like this:

...and I've been very happy with the difference. The new version (bright green on black) is much easier on my aging eyes, and from what Scott says, I think it'll be easier for my audiences to read as well when I'm giving talks at shows or in the classroom. Thanks for the tips, Scott. I'm always reminded that the more I learn, the more I realize I know nothing.

And secondly, I've been meaning to get a good keyboard for a long time now. This article reminded me that as a developer, my keyboard is my main instrument, and that it's a very cheap investment to buy a good one.

"As a corollary to We Are Typists First, Programmers Second, a quality keyboard is one of the best (and cheapest) investments you can make in your career."

"Whatever your choice, give your keyboard the consideration it deserves; it is the one essential tool of our craft."

So a shiny new dasKeyboard is on its way. I opted for the wimpy one with the labeled keys because hey, sometimes I just need to look at the keyboard. Oh, and I also noticed that coding legend Fritz Onion is now searching for keyboard stickers for his blank keyboard, so I figured I'd save myself some grief. I learned to program on a clicky IBM keyboard, and it was, well, delightful to use. I'm looking forward to getting back to basics!

Top 25 Most Dangerous Programming Mistakes

2009-02-05T14:50:14Z

From Coding Horror, originally from CWE/SANS, this is a list that every developer should review from time to time.

If you work on software in any capacity, at least skim this list. I encourage you to click through for greater detail on anything you're not familiar with, or that piques your interest.

Improper Input Validation
Ensure that your input is valid. If you're expecting a number, it shouldn't contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.

...

Read the whole list.

Is Intellisense for XAML broken for you in VS 2008?

2009-01-28T21:26:03Z

I just fired up my first WPF project since I installed VS 2008, and intellisense wasn't working in my XAML files. Like many other graybeards, I prefer to edit XAML files in the XML editor, rather than the designer. But I can't live without intellisense!

If yours is broken, the trick to fix it is probably as simple as ensuring that your default editor for XAML files is the Source Code editor, not the XML editor. Just close your XAML files if they are open, right click on one, and choose "Open With..." from solution explorer. Select whatever version of "Source Code (Text) editor" you prefer, and click "Set as Default". That worked for me.

Hope this helps!

My quest to programmatically generate a self-signed cert that makes IIS happy

2009-01-28T19:45:07Z

I recently published Self-Cert, a tool that makes it really easy to generate self-signed certificates using the CryptoAPI. What's nice about it is that it has a .NET class library underneath it that makes it easy to do this programmatically from managed code as well. The code is currently using CertCreateSelfSignCertificate, and it seems to work great, except that IIS refuses to set up an SSL session using one of my certs.

After quite a bit of experimenting and searching, I determined that the problem didn't have anything to do with my cert creation code, but rather it had to do with the way I was importing the resulting certificate into the certificate store.

The details are still not entirely clear to me, although I've fixed the problem based on a comment left by David Wang on a question posed on an IIS newsgroup. Two lines of code was all it took for the fix, right before I call X509Store.Add to add the cert. I export it to a PFX blob, then reimport it with a flag that indicates where the private key is stored:

byte[] pfx = cert.Export(X509ContentType.Pfx);
cert = new X509Certificate2(pfx, (string)null,
    X509KeyStorageFlags.PersistKeySet |
    X509KeyStorageFlags.MachineKeySet);

This makes the code work, though this feels a bit like cheating. If you know a more elegant solution, let me know, and I'll incorporate it!

I've updated the bits with this fix, and added a version number. This fix brought it up to version 1.1.0.0.

Enjoy!

Some tips on building better password storage for web sites

2009-01-27T21:10:59Z

Mike Woodring sent me an email today. He was concerned that a website that he frequents wasn't doing such a good job storing passwords. He pointed out that by clicking a button, you could get your password emailed back to you. After talking with someone at the website, he discovered that at least the website wasn't storing passwords in cleartext, but they were instead encrypting those passwords and storing the ciphertext.

Mike's concern about this makes sense. When you build a website that accepts passwords, you are taking on a huge responsibility, because you need to remember that many people tend to use the same password everywhere. So if you store the user's name, email address, and password, and if your password database is compromised, your users might be in danger of having their bank accounts, etc. compromised. This is really scary stuff, and I've never envied developers who are in the position of building and maintaining such user account databases.

Here are some things you can do to help protect your users if you are storing their passwords:

1) Store the passwords using a strong, cryptographic one way hash such as SHA-256. And use a long, random, salt value unique to each user. This will slow down a dictionary attack if someone is able to steal your password database.

2) Ensure that your website doesn't allow unlimited failed login attempts.

3) Implement a password policy that is strong enough for the level of security you need. Accepting three character passwords is just silly (the site Mike pointed me to allowed that, by the way). The higher value the website, the longer and more complex your passwords should be.

4) Consider stretching the password by hashing and rehashing that hash, N times. PKCS #5 is an example of this, and there's a class in the .NET Framework that makes this trivial: System.Security.Cryptography::Rfc2898DeriveBytes. This allows you to increase the strength of your password hash over time (by increasing N), so that Moore's law isn't only working in the attacker's favor.

There's no excuse for websites not to do at least (1) and (2).

(3) and (4) are important considerations for higher security websites, but then you should be asking yourself, why am I using passwords to protect a high security website?

What's the ultimate solution to this problem? Instead of storing a password for a user, in the future it'll be much easier to federate with an identity provider that can deal with all the hard issues of client authentication. But if you're not ready for that, there are still other alternatives, such as using SSL client certificates or information cards.

Self-Cert and IIS

2009-01-27T15:01:00Z

IIS is currently rejecting self-signed certs made with the Self-Cert tool. Actually, you can install the cert into IIS, but when a client connects, IIS will refuse to set up the SSL tunnel. So far I believe the problem is that my certs aren't getting an Authority Key Identifier extension, (CertCreateSelfSignCertificate doesn't create one by default).

Working on it...