Didier Stevens

Due to the current media attention, I’m updating and posting this old draft about secret questions.

First, let’s get a pedantic observation out of the way: Secret Question is a misnomer. If you think about it, it’s the answer that is secret, not the question.

The problem with secret questions is that they are often a backdoor to your account. When you use a strong password, the answer to your secret question will be easier to guess than your password. So you are actually using weak credentials.
If the sole purpose of the secret question is to reset your password (or e-mail it to you), then don’t use it, just type some random characters for an answer and forget about it. You won’t be able to get into your account using the secret question backdoor, but so won’t attackers.
If you’re afraid that you might forget your password, write it down and keep it safe (I recommend KeePass if you need a password manager).

Now if you definitely want a backdoor because you don’t want to write anything down and don’t trust your memory, there are a couple of options open to you.
If you’re not able to make up your own secret question, but have to choose one from a predefined list, then provide an answer that you can derive from the question only (think about it, your secret answer doesn’t have to make sense, it just has to be secret). An example:
Q: Name of first pet?
A: Four
Why four? Because the question is a sentence of 4 words. This way you don’t have to remember your secret answer, just the rule to derive the answer from the question. You can reuse the same rule for different accounts, it will generate different secret answers for different secret questions.

If you can provide your own secret question, then I recommend to use math. An example:
Q: How much is 3 + 7?
A: 20
Why 20? Because your secret rule is to double the result to obtain the correct answer. 3 + 7 equals 10, 10 times 2 equels 20.

Secret answer rules can be as hard as you want, but complex rules are more likely to be forgotten…

To summarize: disable secret questions, and store and protect your credentials.

This post comes with a complementary cartoon.

No breaking news in this post, but I’ve found enough applications vulnerable to XML-bombs and not enough awareness around it, that I feel it justifies another web page documenting the principles behind it, together with suggestions to protect your applications from it.

The XML-bomb is a small XML document designed to expand to a gigantic size when parsed by an (unprotected) XML-parser. The huge amount of resources (memory) consumed when parsing the XML-bomb can cause a DoS or BoF.

Take this simple XML document:

And take this Document Type Declaration defining an entity e0 with value A:

Including this DOCTYPE in our simple XML document enables us to reference entity e0 in our document, for example like this:

When this document is parsed by an XML-parser supporting DTDs, the entity reference is replaced by its value. Here is Internet Explorer rendering our XML document:

Notice that &e0; has been replaced by A.

This entity definition and referral mechanism is one essential ingredient of an XML-bomb.

The second ingredient is an expression that will grow exponentially and consume huge amounts of resources when evaluated.

We define a second entity, e1, referring twice to our first entity e0:

Include this definition in our XML document:

And this is how it is parsed:

e0 evaluates to A

e1 evaluates to AA

Now define e2 referencing e1, e3 referencing e2, …, and then we get

e2 evaluates to AAAA

e3 evaluates to AAAAAAAA

…

We have achieved exponential growth! An XML-bomb with 31 entities is less than 1K in size, but entity e30 is 1GB  (2^30 bytes) in size when it gets evaluated by the XML-parser!

How do you protect your application from an exploding XML-bomb?

If you don’t need support for DTDs, just disable DTDs or use a parser without DTD support.

If you need support for DTDs, try to prevent XML-bombs from entering your XML-parser by known-pattern scanning (like classic antivirus software does, for example an application firewall) or limit the impact of an expanding XML-bomb by hardening your XML-parser by restricting its consumption of resources.

You’re aware of the limitations of known-pattern scanning. This is a text-book XML-bomb, with exponential growth finding its origin in the binary tree structure. But there are many other data type structures …