Live data from Hacker News

NXP has messed up their password form validation

peterme.net

11–20 of 36 posts

Re: NXP has messed up their password form validation

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

Re: NXP has messed up their password form validation

#12
post #7

That's not the worst I've seen, either. Some other password sins include: - the password validation fails for reasons not listed entirely - the password box truncates passwords silently

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

Re: NXP has messed up their password form validation

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

Re: NXP has messed up their password form validation

#14

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.

Re: NXP has messed up their password form validation

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

Re: NXP has messed up their password form validation

#16

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

Re: NXP has messed up their password form validation

#17
post #8

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.

Meh, the financial industry has bigger password shenanigans that NXP's dumb form.

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?

Re: NXP has messed up their password form validation

#18

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

Re: NXP has messed up their password form validation

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

Post reply on HN