Ok there are a couple of things which need to be addressed here:
1) As Celegorm said, punctuation and special characters can cause havoc on back-end systems (SQL being the most common, but by no means the only one). These vulnerabilities in this instance come from any free-form text entry box on the internet (such as this one!) - however, more generally they arise from any mechanism where a user is able to send custom content back to the server. The solution in this regard is to ensure that
all user-supplied content is sanitised/parsed as benign text and not interpreted as commands.
That said, this (nor anything else) is a valid reason for not allowing
any character to be used in a password field (usernames and stored content is different). A secure password policy should:
a) allow any character to be used
b) impose a minimum length restriction of 12 characters (ideally more, absolutely never lower than 8 - it's pointless even having a password at this length)
c)
not impose a maximum password length (this is a definitive indicator that d) is not being done!)
d) use salted hashes on all passwords
on the client machine so that the password is never transmitted over the network (including HTTPS)
e) preferably use a secure hashing algorithm such as SHA-256, but failing that anything except MD5
f) separate the username/salt database from the password hash database
g) encrypt the password hashes database with 256bit symmetric-key cryptography (such as AES256) to prevent offline attacks on the hashes in the event both the username/salt database and the password hash database get stolen (it happens
all the time!)
If a website ever emails you your password then they have
definitely violated c), d), e) and f) above - and likely g) too. Password recovery should be done via a reset-password feature with multi-factor authentication that you are the account owner (e.g. SMS, email etc.)
Additionally, if a website ever imposes a
maximum password length then they are
definitely violating d), e) and f) above - again probably g) too. This is assured because a hashing algorithm, such as SHA-256, will
always return a 256-bit (32-bytes) block of alphanumeric characters. Therefore the buffer that is receiving this data on the server only ever needs to be 32-byte big. A fixed maximum of 16 (for example) almost certainly means that there is a 16-byte character buffer on the server which, if not bounds-checked, is vulnerable to buffer overflow (much more dangerous than SQL injection) which can lead to the entire server being taken over by an attacker.
2) As for the OP question about the actual maths behind the subject, take a look at the 'Random Passwords' section of wikipedia page:
https://en.wikipedia.org/wiki/Password_strength which essentially says that the 'x' in your question relates to the number of bits of entropy the password has. This is a function of the
key-space (number of possible characters accepted by the website, hence step a) above is vitally important) as well as the actual number of characters used by the user.
In simplified terms, this can be easily understood by saying 'guess a 4 digit pin' vs. 'guess a 4 character password' - even if the latter is restricted to only lower case, there are still 26 options for each symbol rather than 10 - so you're likely to guess/crack the pin number
much faster.
One final point on this which I can't stress the important of enough is this:
It does not matter how many character sets (e.g. digits, special, upper, lower) your password makes use of - only how many the website allows.
For every extra character set, an additional lump of entropy is available to the users which makes any attempt to break the passwords vastly more difficult and time consuming.
If the website enforces you to use a subset of these then this immediately gives attackers information - in short, make the number of accepted passwords as large possible and don't allow dictionary words which occur in all rainbow tables (this dictionary word check is an additional step which I forgot to include in the original list, but is an exceptional security mechanism).
I hope this has helped you understand password security concepts better, and that you try to educate others along similar lines. If it wasn't already obvious, this is a particular irritant of mine with online services using poor password policy.
Happy surfing!
