Live data from Hacker News

NXP has messed up their password form validation

peterme.net

21–30 of 36 posts

Re: NXP has messed up their password form validation

#21

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.

Yeah 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

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.

Re: NXP has messed up their password form validation

#22
post #13
post #11

I want to insert the "first time?" meme here. 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 pass…

Well that didn't format how I wanted it to. Sorry about that to whoever reads this.

It's okay. Bad textbox fields like this are everywhere :-)

Re: NXP has messed up their password form validation

#24

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.

Yeah 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

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.

Re: NXP has messed up their password form validation

#25

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…

Couldn’t you have used the forgotten password flow?

Re: NXP has messed up their password form validation

#26

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.

> Special characters are usually allowed only from a predefined list. I don't see how this is specifically bad or deserves a blog post. Why limit it in such a way? if the backend is so fragile it can't handle a + sign then it is bad

[deleted]

Re: NXP has messed up their password form validation

#27
post #4
post #3

That is a very good sign that you should avoid NXP. I wish that I had. Designing in their parts are the worse mistake of my career.

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!

Posted a nice rant about NXP and the system here crashed.

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).

Re: NXP has messed up their password form validation

#28
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.

Re: NXP has messed up their password form validation

#29
post #13

Earlier quoted context omitted.

Well that didn't format how I wanted it to. Sorry about that to whoever reads this.

It's okay. Bad textbox fields like this are everywhere :-)

This is the most infuriating thing in Markdown.

Like... why? I never ever need a separate lines stitched together, but I do need a line breaks.

Re: NXP has messed up their password form validation

#30
post #25

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…

Couldn’t you have used the forgotten password flow?

There was some reason why that wasn't working, perhaps that the email was also old and I didn't have access.
Post reply on HN