Hacker News new | ask | show | jobs
by binarymax 4453 days ago
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.
4 comments

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?