Essays mature
This idea is complete, spare the occasional tending.

series: Login Bingo ➤

by Matthew Lyon  • 

It’s time to go log in to the system to do the thing. This is your second time using the system – last time you had signed up, and when you did, you created a nice long password because either that’s what your password generator does, or it’s something you legitimately need to remember and you know that a phrase is both more secure and easier to remember than some cryptic string of characters.

Upon attempting to log in, you discover the username & password combination saved in your password manager isn’t accepted. That’s weird. You go about resetting your password, and the process involves having you log in through the normal means after doing so – unlike after having created the account. But upon attempting to log in immediately after resetting your password you’re again told you’ve provided invalid credentials.

Perhaps this goes on for a while. Perhaps you contact support. After a while you discover that while the system will save your entire password, the verification process only compares the first 16 characters of your password. Maybe the support agent told you this apologetically. Maybe you discovered that the field silently stops accepting input after a while.

And so you settle for a shorter, weaker password and make a note in your password manager that this system doesn’t honor what it accepts, so you don’t go through this again.

Whatever the excuse, if your system accepts someone’s credentials as valid when they create or update them, and then does not accept the exact same credentials upon verification, your system is broken.

I have encountered this problem in the wild so many times I have lost track. I’m aware of having suffered through the following variations:

  • truncating passwords when validating them but not when creating them: such that when creating correct horse battery staple only correct horse ba is used for validation

  • accepting space characters when creating the password but eliding them when verifying it: if I set correct horse battery staple as my password, it would accept correcthorsebatterystaple but not the original

  • automatic case-shifting when creating the password but not when validating it: if I set Correct Horse Battery Staple, it might accept one of correct horse battery staple or CORRECT HORSE BATTERY STAPLE, but not the other and certainly not the original

  • other types of automatic character substitution, typically replacing emoji (🚫) or extended characters (𝖕𝖆𝖘𝖘𝖜𝖔𝖗𝖉) with something else, typically from the ASCII printable character set during the setting of the password but not when validating it

It’s not hard to imagine other variations. Truncation is the most common variant of this I’ve seen — I first remember encountering it on a major merchant services site in 2003, and have most recently encountered it last month on a health care website.

Some years ago, an employer project was an early customer of AWS Cognito, and at the time we discovered that it silently removed space characters from passwords when setting them, but not when verifying them. After some complaints they instead returned errors when creating a password and many years later they made accepting space characters a policy setting. Why this was an issue still remains elusive — perhaps an internal customer demanded it.

I do not know how to make you understand this if you do not already, but you should not store passwords in plain text and if you do need to transform a user’s input before hashing it, do it minimally, and do it consistently across space and time.

I don’t want to steer this series into the broad waters of why password rules are bad but, practically, there is going to be a limit to how long of a password you can store — even if you’re hashing it — because you don’t want malicious actors denying service by tying up your resources by stuffing entire novels into your password field. Stick with a sensible input encoding such as UTF16, pick a sensible grapheme limit such as 256, don’t repeat yourself when applying the truncation, and then never, ever, change it.

But don’t, please don’t, turn an apple into an orange when setting credentials, and then compare it to the apple when verifying it.