This looks like Hyundai Bluelink, and if it's not, then it has the exact same issue. The old password was a generated password provided by support.
Whatever site that is, make sure you use a burner email, burner pw (if you get it to work) and joe doe contact info.
To me it looks like their frontend guy just copy/pasted the password field with all validation over without thinking twice. I wouldn’t say this speaks to their general security competence.
While that may be true(copy/🍝), it implies that their code quality and QA process is broken and some of the most important fields/data are not being closely looked it. It certainly DOES speak to their overall security competence.
Eh, I can see how it's missed by testing. The tests probably cover testing non-compliant passwords failing and compliant passwords passing. They were probably updated at the same time the password compliance was updated.
Missing an edge case like this isn't good, but it's not that uncommon.
Again, a basic code quality issue. If they missed this basic functional code issue, what else did they miss that is exploitable….
Could also be backend validation is broken, so FE just shows the user something useful rather than waiting for backend to reject and show a generic error message.
Found the FE dev. I think there is a JavaScript library for finding ways to blame the backend.
I mean... I've been both. I have had to punt a problem that caused FE anguish because the project is old, not the priority, and hard to make changes to.
I've also been the FE that was told that they are aware of the problem, and can't get to it for a month, so we need to at least make the UI surface the error in a better way so that the user can go to support for manual intervention.
That would be actively malicious. I don’t know how anyone could get the idea to just show “something” if the backend sends a generic error message.
I’m not sure what’s wrong, but have you checked if your tomatoes are fresh?
Huh? If backend has incorrect validation on the old password string, and returns an error message like "invalid password" without specifying if it's the old or new password, that's not particularly helpful for front end. And that's pretty common for an API response not to have fine grain details.
The UI is capable of validating up front before the service request, assuming they know the exact validation rules BE uses.
Or the FE just fucked up. Both are plausible.
Been there, seen that. I got a login into the mainframe of the hospital I was working at. After the first login, it prompted me to change my password. So I did. It had a field width of 12 characters for the password which I used completely.
I logged out and tried to log in again. And found that the login screen password field only allowed for 8 characters.
I got my password reset, chose a new one with only 8 chars, and the first thing I did after completing the login process was to file a bug report. My boss was completely shocked when she got a copy of the report (basically asking who the f-ck is complaining about the computing centers software), and even more shocked when I told her where and how to submit a bug report herself. She had a notebook listing things that had annoyed her to no end on the system...
She had a notebook listing things that had annoyed her to no end on the system...
I like this. Feedback gives me something to do. Make something better.
What if the requirement is that it doesn't match the previous password?
Edit: never mind. Tired brain.
