There simply is no legitimate reason to limit the special characters one can use in a password, as the site in the image for this post is doing. The reason this was done in the past was because of the risk of SQL injection. However, if one is using stored procedures and/or parameterized queries (and that is absolutely the best practice and has been for at least 20 years), it is not a risk. These requirements make it harder for people using password managers, because then one has to fiddle with the password generator setup for just that site before generating a new password.
Problem two with this site is that it appears they have an unpublished maximum size for their passwords. I generated a 30-character password – which is my current default length for new passwords – and it would not accept it. I double-checked that it otherwise met their requirements, but it did not work.
You may be thinking that seems reasonable. After all, they have to have field size limits. For normal fields, this would be true. However, if they are properly salting and hashing my password using the currently recommended hash routine PBKDF, the result is the same length – no matter how long my password is. You can try that out here. This implies they aren’t securely storing my password, which is a pretty big problem if true.
The third problem is that they are requiring me to change my password on a regular basis. This is actually less secure, because it encourages bad decisions by people who aren’t using password managers. Typically users will just use some variation of their current password (increment a number, change a date, etc.) or use a pattern password. It used to be the recommendation that passwords be regularly updated, but that isn’t the case any longer. Now, unless there is evidence that a password is compromised (which can easily be checked here), there is no reason to make users go through this bit of security theater.
I have contacted them noting my concerns. If I get a reply, I’ll post it here.
