I needed to get a certificate for digitally submitting my taxes. This, of course, requires me to set a password for it. The tax office’ web site lists a number of requirements and rejects any password that does not match those (so it said). So far, so good, the usual stuff, lower and upper case, numbers, special characters, minimum lenght. No surprises there.

For one of the “special characters” I used “ö” (umlaut o), which is a normal character in my language (which is the same as the tax offices, so they should be aware of those). The web site filter happily accepted this password containing the “ö”. But the back engine got a severe case of digital diarrhea from it. I had to clear my caches and cookies to completely re-starting the application process.

Another password SNAFU I had many years ago in a place using TN3270 terminals. To those who have never seen such a thing, it is a so-called “smart terminal”. It does not send and receive single characters like a telnet or SSH session, but the host sends a mask to the terminal, defining fields that can be filled out, and with a “send” or “function” key (IIRC) you could send the data back. Those fields had fixed lengths, of course. You might guess the problem…

So the login screen had two fields of eight characters each: “Username” and “Password”. I entered the credentials I have been given and sent them. The first thing I did was to select “change password”. It opened a form with three fields: “old password”, “new password”, and “repeat new password”. Nothing odd about that, but the fields had twelve characters. So, not knowing the particulars of that system (I was used to UNIX style terminals back then), I entered a new password that was longer than eight characters. Guess what? I logged out, I tried to log in, I was stuck. I had to ask my admin to reset my password. And had found the first of many, many bugs in that system.