It was noted as a backdoor. Presumably that means it was purposefully programmed in for testing (and possibly even production), and made its way into the delivered software. So the under-the-hood speculation being a simple if statement allowing for all-space passwords to grant access.

Sounds more like a bug than a backdoor. I would think spaces aren't an allowed character. Likely their validation regex didn't expect a series of spaces, and this edge case not being caught, somehow allows access.

Developers put these kinds of bypasses into login code quite frequently. When you're testing and fixing bugs typing in a password over and over gets old. As the poster above noted, the code is usually surrounded by conditional compilation directives, or otherwise marked as not being permissible in a production build.

Spaces are in fact often, if not always, an allowed character for passwords, at least in Microsoft/Windows systems. See "Use Spaces in Your Windows Password for Extra Security"[1].

[1]: http://lifehacker.com/5733535/use-spaces-in-your-windows-pas...

That's how it was reported, but given the rest of the article, I suspect that isn't a technical term.

Really the whole thing reminds me about how I used to break the parental locks on my TV as a kid. I doubt this kid was the first to discover this, but probably because of the work his father does, they were able to make the right right calls and send the right emails.

That was the first thing that came to mind, too. It isn't unusual to program in a shortcut like that for the QA team. It just looks like it was missed when they rolled that code out.

It just goes to show (if my assumption is correct) that it's worth NOT adding in those efficiencies, when possible, because of situations just like this one.

No, that's why you tie that kind of code to a compiler flag.

I feel kind of dumb for asking this, but how do you do that?

Depends on the language/compiler/linker/preprocessor/interpreter/etc.

I'm not really a C developer, but since it's a lingua franca, GCC lets you pass in -D (name), which will define that passed in as a macro, letting you do stuff like

  #ifdef DEBUG
  //Do debug stuff
  #endif

so that if you run gcc with -DDEBUG, you will have DEBUG defined and set to 1 (you can also do DEBUG=val and similar I believe), and if you don't, it will be removed.

Java, I don't believe javac has a similar compiler mechanism; you either need a hardcoded global value in the source code

  public static final boolean DEBUG = true;

and you can do similar

  if DEBUG { (...) }

and then for your prod compile you set DEBUG to false and recompile everything; or, you can swap out implementations of a particular class, and have everything code to the interface (all that typical Java IoC dependency injection joy).

For any other language, consult your documentation. If there's nothing else, and the language allows you to pass in arguments into the runtime executable, you could always do something really ungainly like accept an argument for 'environment', and have code that executes differently based on that. It's a minimal cost (since any given run will lead to that particular switch always executing the same way, I'd wager your CPUs branch prediction is going to effectively make it free, but even if it doesn't, it's minimal impact), and it lets you execute the code differently based on what environment you specify you're in.

In C and C-derived languages, the C preprocessor can do some work on its own before anything ever hits the compiler. You can put a block of code like:

    #ifdef DEBUG
    if (pw == "backdoor")
      return true;
    #endif

And then when you want to have your backdoor active, just #define DEBUG somewhere upstream. That way, the backdoor code will never even be compiled in a non-debug program.

It can be as simple as:

    #ifdef DEBUG
    ... code ...
    #endif

The article mentions the field was for a verification password; would Microsoft really admit that they'd implemented such a backdoor (a very strange one at that)?

To me it seems more plausible that the verification answer was a series of spaces. Perhaps the bounty was paid for noticing insecure verification answers weren't rejected?

Not sure, but I had a similar bug once due to a trim() combined with an out-of-order string length check. But that would imply that Xbox Live does not allow passwords with spaces or something.

Maybe leading and/or trailing spaces.

Conjecture here, but maybe the code checks the length as greater than 0, and then trims the string. Depending on how the string comparison is performed, that empty string might pass.

This can't be the Xbox Live account password, because surely that is sending hashes over the wire and not plaintext. Maybe the parental controls don't have the same kind of security, but I don't know that it is needed.