Classic UX advice is to give useful, informational, actionable error messages. For example, the Nielsen Norman Group recommends:

Concisely and precisely describe the issue. Generic messages such as An error occurred lack context. Provide descriptions of the exact problems to help users understand what happened.

[...]

Offer constructive advice. Merely stating the problem is also not enough; offer some potential remedies.

Tim Neusesser and Evan Sunwall (Nielsen Norman Group): Error-Message Guidelines

Are people just ignoring tried-and-true UX wisdom, or is something else going on? I argue it’s something else.

Any decent error message is a kind of oracle. Bad error messages are usually not incompetence, but the result of specific tradeoffs in the design space. What’s ahead:

• Everyone’s least favorite login errors

• Any decent error message is a kind of oracle

• How I learned to stop worrying and love the oracle

• Meaningmaking for our error messages

Everyone’s least favorite login errors

As a user, the worst kind of error message is “Username or password is incorrect,” followed by “If the account exists, we sent you a password reset email.” This goes against classic UX guidance about good error messages. 

So why aren’t these errors better? “Password is incorrect, try again.” or, “No account exists for this email.” Is that so hard?

Actually, these kinds of error messages are designed to avoid an account enumeration attack - a way for an attacker to understand whether a particular email has an account on your site. Is that so sensitive? If you run a mental-health app or similar, it could be! And account enumeration often precedes credential stuffing, where an attacker uses previously-breached passwords to get into other accounts where the person re-used the password.

(Side note: that link above goes to my employer’s site, but my writing here is always my own.)

Many “Oopsie woopsie”-style errors are a fallback message that appears in unexpected errors - since the developer doesn’t expect it to happen, it could be dangerous to reveal application context as part of the error. As someone working in security, I absolutely do not want to reveal information about my defenses to a possible attacker. 

This is our first potential oracle: the login page that knows what really went wrong, but might not tell you the truth.

Any decent error message is a kind of oracle

Let’s talk about encryption itself. We know already that encryption isn’t enough to ensure security, but in cryptography, even error messages can be dangerous. 

If we want to encrypt some data, we might use Cipher-Block Chaining (CBC) encryption, which splits the data into fixed-size blocks and encrypts them. To make sure all blocks are the right size, you’ll extend your data with padding of a known format.

What if you add the padding data wrong? Wouldn’t it be useful if the decryption code gave different errors for “couldn’t decrypt due to wrong key or IV” and “couldn’t decrypt due to wrong padding”? 

If you think so, congrats - you’ve just introduced a padding oracle attack. The decryption code’s error message is the “oracle”: you might not know if your padding is correct, but the wise oracle can tell you. But what happens if an attacker can talk to the oracle too?

An attacker can decrypt a stolen message by changing one byte at a time, and seeing if that results in correct padding. They’ll get one byte, then next byte, and so on until the entire message is decrypted.