There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on".
Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and unnecessary coupling.
That said, I could definitely see additional checks being done server side. One example would be actually checking the address database to see if service is available in the entered address. On the other hand, there really isn't any waste here either. I.e. just because you write the validation in server side JS doesn't mean you MUST therefore deploy and use it in the client side JS as well, it just means you never need to worry about writing the same check twice.
function basicValidatePassword(password) {
const minLength = 8;
const maxLength = 64;
const isValidChars = /^[A-Za-z0-9]+$/;
const hasUpperCase = /[A-Z]/;
const hasLowerCase = /[a-z]/;
const hasSpecialChar = /[\W_]/;
const results = {minLength: password.length >= minLength,
maxLength: password.length <= maxLength,
hasUpper: hasUpperCase.test(password),
hasLower: hasLowerCase.test(password),
hasSpecial: hasSpecialChar.test(password),
hasValidChars: isValidChars.test(password)}
results.isValid = Object.values(results).every(item => item);
return results;
}
Then instead of writing another one on the server that only checks the password isn't blank, is less than the maximum, and has valid characters you're just reusing the full 6 check code. That's only twice as many checks, not even twice as many lines, and it's already written. You really should check all 6 again on the server anyways, but that's beside the point. Better still, if you do the reuse as a build step via shared function library file or similar you don't need to copy/paste and it stays in sync automatically.Of particular note there is no UI code here because the meter's UI code is not related to the check function beyond it reads the return value.
I'm not saying not to reuse things, because I specifically think it should be two separate functions on the client, one of which is copied to the server. But if you insist on having only one client function, I think the server function should be cut down.
And the premise is doing client-only advice on strength so I'm not going to challenge that premise.
As far as 50x, your code doesn't need those consts saying the exact same thing as the results object, so that simplifies to 8 lines, and I think 400 lines for a good password estimator isn't unreasonable. zxcvbn's scoring function is around that size.
Also, in my opinion things like you suggest you shouldn't do. A password strength metre is only going to give attackers hints at the passwords you have in your system. And I have not see a caps lock on warning in forever. The only password validation we do is the length which is pretty easy to validate on client and server.
No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.
In the full picture though, in terms of UI/UX, the meter seems like only a downside. In the dartboard use case it's great because it displays what's still needed in terms users work and think with signalling e.g. "you still need a number, otherwise you're all set". People don't really think in bits of entropy though so ll that really is being signaled by either a meter or a normal failed validation hint is "more complexity and/or length needed".
There may be good cases for using a meter while simultaneously implementing good password requirement policy I'm not thinking of though.
This works like I described, it don't show 'dartboard requirements', only entropy. I think you've misunderstood what a password strength checker is. It's definitionally not a checklist like 'You need an uppercase letter, a lowercase letter, a number, a special character'. It's a tool which measures the strength i.e. the randomness or entropy of the password.
You still need the client side validation for UX. The regular users needs to know if they messed up someting in the form. Also it's a much better UX if it's done on the client side, without the need to send an async request for validations.
<input type="email" required placeholder="Please enter your email address">
Constantly reinventing the wheel in every app is silly.If your back end is fast and your HTML is lean, backend requests to validate can complete in less time than any of the 300 javascript, CSS, tracker, font, and other requests that a fashionable modern webapp does for no good reason...
It's true though that many back ends are run on the cheap with slow programming languages and single-thread runtimes like node.js that compete with slow javascript build systems to make people think slow is the new normal.
Server side validations predominately enforce business constraints.
If you mix the concerns, either your UX suffers (latency) or the data suffers (consistency, correctness).