Knowing NXP and how much they value SW development, they most likely off-shored this to the cheapest possible sweatshop and that's the result, no need to look to deep into it, it's just how it works over there.
It has been awhile (about 10 years or so), but I can recall at least two widely used enterprise access management systems that had trouble with some special characters. Access management is hard. Even those able to pour boatloads of cash into it don't necessarily get great results. On the other hand, there's nothing hard about providing users with a clear statement of your system's limitations. What ever happened to UAT?
What part did you design? I used an IMX8, and had issues with the CSI-MIPI RX, the fifo kept overflowing and crashing the AXI bridge, which could only be fixed by rebooting the SoC, such a pain!
PayPal does this, which means I lost the ability to use PayPal for a few days because my password manager generated something longer than the 16(!) or so characters PayPal accepts. If you're going to implement a form to set or change a password, you should probably let it accept a length greater than whatever you're going to store and validate it client side (and in the backend for those who have javascript disabled, though you should validate in the backend anyway).
That's a very common pattern. Special characters are usually allowed only from a predefined list. I don't see how this is specifically bad or deserves a blog post.
Yup, anyone who's using a password manager and/or generates passwords runs into these issues from time to time. Super strong passwords being rejected, and have to make them simpler. I'd say I run into this multiple times a year.
Agree. Apple’s default password generator has always seemed to strike a sane balance - plenty of entropy, technically contains special characters (-) but nothing that needs escaped, and very typeable or readable.
Back when I was in school, in the U.K., my password contained a ‘£’. This was fine for logging into Windows or Outlook etc, however the printers required you enter your password and only had a US keyboard layout - so that was fun.
I'd be inclined to agree, but this is rejecting ASCII characters. I can see not supporting emoji in your passwords, but angle brackets have their own key on my keyboard, they should be supported.
As for the blog post it was just a way for me to get some frustration off my chest. It's also posted in the "Scraps" section of my site, which I just use for short one-off things like this. If I then decide to write an article about it later (like a longer thing about password managers and dealing with passwords online) then I could link to these scraps.
Bad password fields like this are everywhere. Some of my favorites:
1. The ones that don't tell you what the restrictions are at all, just that your password is "wrong".
2. Tells you that a special character is required but doesn't tell you which ones are valid and which ones aren't.
3. Password requirements as stated do not match how the password field validates the password. (My favorite which I see a lot: Must be 20 characters or less... only accepts up to 19 characters.)
4. Allows only certain length of password on account creation, truncating the password your manager enters, but the login form password field is unlimited.
5. Silently truncates your password without telling you, even if you enter a longer password.
6. The ones that are either intentionally or unintentionally written such that somehow your password manager can't even find the form fields. Most especially the password field.
7. The ones that won't let you type or paste into them but instead give you an on-screen keyboard you have to key in your password with mouse clicks on a virtual keyboard for "security".
I could go on for days, but there's a lot of really badly written websites out there. At least in this case it was abundantly clear immediately that it didn't accept the bracket. I'd daresay call that login form good compared to some of the crap I've seen.
That's a great list! I've come across many of those, but not all of them (luckily).
The problem with this form in particular was that I got my password manager to type the password for me. So it wasn't immediately obvious where the error was. If you actually typed the password you would see it go red at some point, but for me it just turned red with a seemingly okay password.
One of the funnier versions of this that I ran into was on Instacart’s change password form.
Years ago, they allowed very weak passwords. Eventually they implemented a complexity policy that required longer passwords, symbols etc. They applied client side validation of the complexity rules on their password change form, but they also applied the rules to the existing password. I ended up having to use burp suite to change the request inflight so as to set the correct current password.
Dumb clickbait headline. Sure it’s a dumb form but it’s hardly the first or terribly uncommon to have a limited set of expected special characters. And maybe jaded but my first assumption is that was a set, not an example.
Finance sites, utilities, I think the treasury all have something similar. Maybe this person is super young and doesn’t have to interact with crusty online services.
Not sure why you think it's clickbait? They have messed up password form validation. Sure it's not the worst, not even the worst I've come across. But it's still bad.
And I wish I was super young, but I just live in a place where institutions like that all use a common system tied to your bank which is actually pretty solid. So the times I have to deal with crummy online services it's stuff like this.
Sorry don’t see how they messed up anything. They state the requirements and they give the set of characters meeting one of those requirements. The wording could be improved but that doesn’t rise to the level of “messed up” any more than 99% of the Internet is messed up.
It’s not like the behavior is completely incongruent with any reasonable interpretation of the instructions. That would be messed up.
“ So initially it failed on no special characters in my input. Oh well, easy fix, open up the settings, add the special characters group, and regenerate. Hmm, still no special characters?”
Not sure why you assume there is a standard definition of “special character”. There isn’t. I’m surprised it took you this long to stumble upon this if you use a password manager, but there you have it.
There’s also a lot of words of build up when the first picture with the angle bracket makes it abundantly clear what must be going on.
Nothing enrages me more than an iOS app whose password requirements don’t work with iOS’s default password generator. Apple should fail their app testing.
One thing I miss from my previous password manager was the ability to restrict the special character set in the password generator on a per-entry basis, exactly for this sort of situation. It's not that big a deal to remove "invalid" characters manually but not having to worry about it at all was nice.
35 comments
[ 0.32 ms ] story [ 16.1 ms ] threadI wish that I had. Designing in their parts are the worse mistake of my career.
It was the Kinetis MKL27.
Bottom line is avoid NXP due to broken parts, poor documentation, no errata's, poor support and poor delivery (still getting quotes into 2025).
- the password validation fails for reasons not listed entirely
- the password box truncates passwords silently
PayPal does this, which means I lost the ability to use PayPal for a few days because my password manager generated something longer than the 16(!) or so characters PayPal accepts. If you're going to implement a form to set or change a password, you should probably let it accept a length greater than whatever you're going to store and validate it client side (and in the backend for those who have javascript disabled, though you should validate in the backend anyway).
And let me tell you about the 'super strong password' your generators create: they suck
They suck if you have to deal with any kind of escaping (like in a shell script, for example)
They suck if you're unsure of the current keyboard layout you're currently using
Easier to take out some character classes instead of having to solve support tickets
Why limit it in such a way? if the backend is so fragile it can't handle a + sign then it is bad
As for the blog post it was just a way for me to get some frustration off my chest. It's also posted in the "Scraps" section of my site, which I just use for short one-off things like this. If I then decide to write an article about it later (like a longer thing about password managers and dealing with passwords online) then I could link to these scraps.
Bad password fields like this are everywhere. Some of my favorites:
1. The ones that don't tell you what the restrictions are at all, just that your password is "wrong". 2. Tells you that a special character is required but doesn't tell you which ones are valid and which ones aren't. 3. Password requirements as stated do not match how the password field validates the password. (My favorite which I see a lot: Must be 20 characters or less... only accepts up to 19 characters.) 4. Allows only certain length of password on account creation, truncating the password your manager enters, but the login form password field is unlimited. 5. Silently truncates your password without telling you, even if you enter a longer password. 6. The ones that are either intentionally or unintentionally written such that somehow your password manager can't even find the form fields. Most especially the password field. 7. The ones that won't let you type or paste into them but instead give you an on-screen keyboard you have to key in your password with mouse clicks on a virtual keyboard for "security".
I could go on for days, but there's a lot of really badly written websites out there. At least in this case it was abundantly clear immediately that it didn't accept the bracket. I'd daresay call that login form good compared to some of the crap I've seen.
Like... why? I never ever need a separate lines stitched together, but I do need a line breaks.
The problem with this form in particular was that I got my password manager to type the password for me. So it wasn't immediately obvious where the error was. If you actually typed the password you would see it go red at some point, but for me it just turned red with a seemingly okay password.
Years ago, they allowed very weak passwords. Eventually they implemented a complexity policy that required longer passwords, symbols etc. They applied client side validation of the complexity rules on their password change form, but they also applied the rules to the existing password. I ended up having to use burp suite to change the request inflight so as to set the correct current password.
Finance sites, utilities, I think the treasury all have something similar. Maybe this person is super young and doesn’t have to interact with crusty online services.
And I wish I was super young, but I just live in a place where institutions like that all use a common system tied to your bank which is actually pretty solid. So the times I have to deal with crummy online services it's stuff like this.
“ So initially it failed on no special characters in my input. Oh well, easy fix, open up the settings, add the special characters group, and regenerate. Hmm, still no special characters?”
Not sure why you assume there is a standard definition of “special character”. There isn’t. I’m surprised it took you this long to stumble upon this if you use a password manager, but there you have it.
There’s also a lot of words of build up when the first picture with the angle bracket makes it abundantly clear what must be going on.
The fake reason is to assist password generators.
The real reason is to make it easier to name and shame the sites with the most ridiculous password policies.