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.
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.
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.
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.
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.
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.
Burner PW?
Just use a manager.