When so called secure institutions like banks, insurance companies and others ask you to create a password, you expect them to allow strange characters like ,.$#@{}[] to make the password stronger. To my surprise on several occasions I’ve experienced that they did not accept other than plain letters and numbers! What!? Didn’t the developer that implemented that logic raise a flag??

One specific case is with BankId (a national authentication mechanism for all banks in Norway), where I know the underlying implementation support strong passwords. However, when prompted by my bank to create the password, you’re not permitted. Actually I had to type in a temporary weak password and then change the password in the login screen which support the expected behavior!

At some point there had to be a discussion like this:

Developer: What type of password should we support?

Product Owner: What do you mean?

Developer: Should we allow people to make up their password from everything that they can find on their keyboard?

Product Owner: No, the normal alphabet and numbers should be sufficient. Or else people just forget their passwords.

My above experience with BankId was just an example from today, and in that case there were a workaround, which is not the common case. I always get puzzled when this happens. What puzzles me even more is that to prevent people from entering strong password, you actually have to code a business rule for exactly that! And what about those who only permit numbers!? What’s that all about?

Sorry for this rant, but I think it is important that we as developers, architects and technically skilled people take responsibility to avoid stuff like this to happen. I just can’t see one single good reason for limiting the users choice when it comes to passwords.