Is it a security vulnerability to tell a user what input characters are valid/invalid?

Question

For input validation on a website, are there any security concerns with disclosing to the user exactly what characters are valid or invalid for a given field?

CWE-200: Information Exposure says one should try not to disclose information "that could be useful in an attack but is normally not available to the attacker". A specific example would be preventing a system from exposing stack traces (addressed by CWE-209: Information Exposure Through an Error Message).

Should one ensure that error messages are vague, like "The text you entered contains invalid characters"?

Is it a security vulnerability to include the regular expressions used to validate input in client-side code, such as JavaScript, that would be visible to attackers? The alternative, validating inputs server-side, would reduce usability somewhat as it would require more backend communication (e.g. it could cause the site to respond and display errors slower).

Or is this a form of "security through obscurity" as the user/attacker can deduce what characters are valid by repeatedly submitting different characters to see if they produce errors?

Is it worth the hits to user experience to potentially slow down an attack?

I should note, as far as I can tell, OWASP's Input Validation Cheat Sheet and Data Validation development guide don't provide direction on this topic.

Edit 2020-01-17:

There have been several questions (including answers that I went to the effort of writing comments on that have since been deleted) as to why one should be doing any input validation.

First off, thank you to @Loek for the comment pointing to OWASP's Application Security Verification Standard that provides guidance on passwords on page 23 and 24: "Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.".

I think we can all agree that limiting characters in a password is generally a bad idea (see @Merchako's answer). As @emory points out it probably can't be a hard and fast rule (e.g. I have seen many mobile apps that use an easier to use secondary "PIN" to secure the app even someone else has access to log into the device.) I didn't really have passwords in mind when I asked this question but that's one direction the comments and answers went. So for the purposes of this question let's consider it to be for non-password fields.

Input validation is part of "defense in depth" for websites, web services, and apps to prevent injection attacks. Injection attacks, as stated by OWASP, "can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data."

See OWASP's #1 vulnerability, A1-Injection, and CWE-20: Improper Input Validation for more detailed information. Note they both say input validation is not a complete defense but rather one layer of that "defense in depth" for software products.

Answer 1

... that could be useful in an attack but is normally not available to the attacker

Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users away since they cannot continue.

Answer 2

Creating a psychologically frustrating situation for users could incline them toward less secure decisions. For example, they try to write a password in Swedish, but your input refuses the character å without explanation. Instead of picking a different good password without å, they throw up their hands and use password123—one that's easily defeated with a dictionary attack.

Thus, you have attempted to create a "more secure" system through obscurity, but once we account for user behaviors, it is in fact less secure.

Valid characters are ultimately discoverable through systematic means. Hiding them is not worth the damage you might do to user behaviors.

---

For further reading, see "Security and Cognitive Bias: Exploring the Role of the Mind" and "Measuring the Security Impacts of Password Policies Using Cognitive Behavioral Agent-Based Modeling" by Sean Smith et al.

Answer 3

It depends.

If the message describes an error from the normal users point of view, like "The 3rd character must be a digit", it is not a security vulnerability. But displaying regular expression used for validation means disclosing implementation details which can be a weakness, e.g. some libraries use recursive calls extensively and some expressions can cause stack overflow or high memory and CPU usage, which may lead to DoS.

The CWE-200 defines disclosure of information as a weakness only if user is not explicitly authorized to have access to that information. You are considering user input. Means, user is allowed to enter this information and thus allowed to see this information and naturally he is allowed see any validation error messages related to this input.

Stack trace as well as other technical messages can provide information about the technologies used in the application (e.g. what version of what libraries are used), about the environment (e.g. directory layout and permissions, OS type and version), etc. An attacker can use this information to effectively choose exploits for these particular technologies, libraries, OS, etc. That's why disclosing such information to user is potentially a weakness.

Not explaining the user what is wrong in his input is definitely bad UX, but not security improvement.

Don't confuse that with similar cases, when data is sensitive and any validation related to it can be sensitive. For instance, if user entered letters in the field where you expect a year, then explaining such error to user is safe. But if the user enters an email address and you check if such address is registered in your system, then any information (address is known, address is unknown) can be a weakness. That's why when you are going to implement validation messages or any other feedback regarding user input, evaluate the consequences. But prohibiting any feedback by default for all fields can be a poor UX with a false feeling of security.

Answer 4

This is just one of the many scenarios where security tradeoffs are expected in favor of the usability of the system.

However, there is a huge difference between showing stack traces (poor error handling), and disclaiming which characters are expected or prohibited in an input field.

For most scenarios, one can argue that disclaiming which characters are expected or prohibited in an input field is not a security vulnerability at all, if other security mechanisms are in place, such as limiting password attempts.

It can be determined using a threat modelling framework that this is an accepted risk of system.

Answer 5

Obscurity is not security. A good system is secure even when an attacker knows everything about it. In your case, paring down the wasted cracking guesses by a certain percent, say 25%, should not make-or-break the practicality of cracking: 1 trillion years is just as practical as 0.75 trillion years. Having implementation details not occluded also helps new good guys defend.

There's also social considerations. A "BEWARE OF DOG" sign might leak security implementation details, but it also discourages a certain scale of common attacks. The dog helps, known or unknown, but a sign could reduce fence maintenance costs, which frees resources for fighting other battles.

Answer 6

The other answers show how disclosing this is not a security issue.

I will argue with a true anecdote that not disclosing can lead not only to frustrating users but even to less security.

This happened to me more than once on sites that didn't make clear what characters are allowed. At that time I didn't use a password generator so I had a mental scheme to remember passwords. It involved using a few special characters like $@.&. A few frustrated attempts where all I got was "invalid characters in password" and I progressively started to eliminate special characters. Then came "your password is not safe enough, try adding some digits and symbols" ... yeah ... I am definitely relaxed at this point.

I finally got it to accept my password. Which not only contained just one special character but also didn't fit any of my schemes for remembering passwords so I had to ... hmm ... store it somewhere else (this was before I even knew about password managers so I will let you imagine how I secured it. I will tell you it was like a helicopter and like a string).

Answer 7

I don't see a problem in disclosing the set of characters the user is able to choose from, as long as these rules are on the one hand also enforced and checked. Which is to say, if the user is not allowed to use \ in the field, it is not enough to check this in the JS input, but also before entering this i.e. in the DB and when the data is used. So the rules have to apply all the time (TOCTOU). The other part is, it is no problem to reduce the set of characters, as long as the entropy is still given. You can reduce the Password characters to "a" and "b", but then you have to increase the min PW length accordingly (and check, that they are not only holding the "a" key down until it is long enough). With a long enough (random) password, this also would be a secure password. In the end, all there is to a character are bits, and everyone knows these are 0 & 1, so the (real) alphabet is always known, how many possible arrangements there are, is up to you to specify (and check).