I definitely wouldn't reveal regular expressions to a user: that would neither help usability or security...

Following is just a comment: I don't get upset when a website tells me me list of allowed/disallowed characters, it makes me feel more comfortable that the site is (trying to) implement security correctly. What makes me upset is when they disclose a maximum password length which reveals possible security holes. See also my favourite post security.stackexchange.com/a/33471

@ConorMancone No, I definitely wouldn't display regular expressions to the user, but it isn't uncommon to be able to view the RegEx used for client-side validation on websites using browser F12 Developer Tools. I sometimes resort to using that method when I can't figure out why a website isn't accepting a particular input.

If it's for a password field, and you do not tell me what characters are or aren't allowed, I will do my best to not use your site if possible because random password generation will be a nightmare (also, why would you ever restrict characters in a password anyway...)

@multithr3at3d Agreed. I'm not focusing on any specific field type for this question, but it could apply to a password field.

the fun lurks around the corner .. I remember certain brand router models, that showed a login screen (no user name / login name ) - for password - next to that a textbox explaining that valid passwords are mandatory 4 digits long numbers (ranging from 0000 to 9999) and sugar on top - every model rolled out with unconfigured password which meant 0000 - and even stated this in the textbox "strandard password 0000" LOL And as far as I remember you had to manually disable login from the WAN side, which was open by standard ,,, double LOL

Great. I once used an HMRC form that didn't allow & or < in an otherwise free-format notes field. Total incompetence on the part of the people who designed the form, but at least they tell you. Now you're suggesting that the user should be allowed to type 500 words of text, and at the end they're just told that it's invalid, without saying why? Security doesn't mean making your site totally unusable.

@multithr3at3d Because many keyboards might not have them. If I user thinks to be clever inserting weird unicode characters they may have a real issue when they travel abroad and lose their laptop and have to manually enter it from a chinese keyboard or something like that. It's much better to enforce a longer password than to let user shoot themselves in the foot, especially if you are dealing with important stuff like banks

Why not go one step further? Don't tell the attacker which box is for the username and which box is for the password. In fact, randomly sometimes give them two username boxes or two password boxes just to confuse them.

i would think that if invalid characters are a security concern, something has already gone very wrong

@Eevee Well, we’re talking layered security. OWASP and others recommend “whitelist” input validation to prevent injection attacks. They point out it isn’t a complete defense but it is one of many things they recommend doing to prevent attacks.

Others have adequately answered the primary question: sure, tell the users what characters are allowed. However, note: if there's a security reason that your server side needs the input restricted, that restriction must be checked on the server side. Feel free to check on the client side in addition, for UI reasons, but you must assume that the client side has been taken over by the villain and will feed malicious data to the server. (And if there's such a security reason, you should probably be re-examining your server side...)

@JordanBrown Rather, always assume the user isn't even using your frontend. A malicious user can pretty much always just use curl if they want to hit your API directly. The frontend is nice for user experience and such, but very few attackers would actually go through it (easier to figure out what your validation is and then curl valid requests at it to probe for vulnerabilities).

I'd worry that an update would accidentally prevent a user from being able to enter a previously valid (but migratable) password. Sure, they can reset their password, but they'll be confused why it didn't work.

One thing I wish websites and servers would do better: you tell me what characters are allowed when I'm creating an account, but not when I'm trying to remember my password... It doesn't help the hacker any to give this information because they can just pretend create an account. So tell me what characters were allowed when I entered my password so that I can recall which one it is.

@multithr3at3d The problem I've seen with password-fields and "not telling the users" is not that some sites restrict the characters allowed in the password, but that they don't tell you what is required for a password to be acceptable. The BACS website (for UK direct payments / direct-debit collections) used to periodically force you to change your password. When you entered a new one, it would sometimes say that it didn't meet their rules (e.g. mix of letters, numbers, symbols; etc.) but didn't tell you what those rules were!.

@usr-local-ΕΨΗΕΛΩΝ Wouldn't having any characters explicity "not allowed" automatically reduce entropy thus making security worse? Even worse so if you display a list of those characters so brute-forcers know which characters will never be contained in a password... blog.codinghorror.com/password-rules-are-bullshit

@Delioth Sure. Using an entirely different client is kind of the extreme example of "taken over by the villain". The villain will study your client, and will either modify it or create a new client that bypasses the client's checks and attacks the server.

I would like to comment that OWASP's ASVS sheet does provide indirect guidance on this issue on page 21 and 22: "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." github.com/OWASP/ASVS/blob/master/4.0/…. There are also other rules like 2.1.1, 2.1.2 and 2.1.4 that answer your question indirectly: you should not need ask this question because you should not use a regex to validate.

@Loek Agreed; we shouldn't restrict password inputs. I updated my question to reflect this. Please see rule 5.1.3 of the ASVS (currently page 35): "Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting). (C5)" and 5.1.4: "Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern [...]"

@GrumpysaysReinstateMonica yes reducing the alphabet does reduce security and make security worse. However in certain situations 1, l, and I may be confused. Maybe it is better to remove some of them if that causes problems. Maybe the user sometimes has a cyrilic keyboard and sometimes not. Maybe it is just easier to disallow cyrllic characters in the password than having to help the user login when they do not have access to their cyrillic keyboard. I think it is a tradeoff

@csrowell I think in general character restriction is bad. I think for the specific reasons I mentioned, probably the Facebook solution is better than character restriction. However, since if you think it possible that your users will need to input their password using only a telephone keypad, I can not say as an absolute that there are never any occasions which it would make sense to restrict characters.

@emory Good point. I'll revise my question to state that it's "generally" a bad idea to restrict password characters. Certainly I have seen many mobile apps that use a secondary "PIN" to secure the app even if you are able to log into the device.

I don't really see why this was moved to chat - it's not like there was a quick-fire back-and-forth conversation going on here....