I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?
Some validations require capabilities that you don't want/need the client to have.
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.
I'm not sure adding a meter value output to the server side check to use it in both places is really more engineering work. Writing separate checks on the client and server side seems much more likely to create headache and extra work.
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.
I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any engineering work by writing a 2nd validation function on the server side instead of just ignoring the extra info in the one that already exists?
In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.
You shouldn't have to port anything. If you mean in the opposite case of two separate languages between client and server side then yeah, of course - by definition you're rewriting everything and there is no way to reuse code. I'm not clear how you're reaching anywhere near 50x complexity though. You're writing something like this on the client side (please excuse the lazy checks):
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.
If that's all you want then sure, but that's not what I would call a good password quality meter. It makes no attempt to look for patterns or words or super-common passwords.
As noted excuse the basic check functions and use whatever you actually want for check criteria and the amount of work on the server side is still a factor <1 compared to writing that and then a different check on the server. If your password check logic is 50x the size of that though you might be overdoing it, but that's just an opinion. Again I'd argue you should really be validating server side as well anyways, fewer chances to mess something up and accept a weak password.
Your check functions are fine, for both client and server.
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.
I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into.
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.
> A password strength metre is only going to give attackers hints at the passwords you have in your system
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.
I'd agree with both takes on that it depends on the meter. Ones which truly approximate password entropy work like you say, however, for some reason, the most common use of such meters is to show how many dartboard requirements you've met while ignoring the actual complexity. When this common approach is used you combine "password must be 8 characters or more" with things like "password must have a number, symbol of ${group}, and capital letter" and the average password complexity is actually made worse for a given length due to pigeonholing.
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.
Everything has to be validated on the server side simply for security reasons.
Even if you do all validation on the client side, which prevents the users submitting a form with invalid data, an attacker can work around that. e.g. submitting the form with valid data, but intercepting the request and modifying the values there. Or simply just using curl with malicious/invalid data.
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.
They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.
Some kinds of validation really do need the round trip. If somebody is choosing a user name on a sign up for you do need to do a database lookup.
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.
Yeah, obviously if it requires I/O you can’t write it client side, but the argument here seems to be in favor of doing validation only server-side even when it could also be done client-side.
Presumably there are some features of the app that won’t work that way. Surely you’re not saying you prefer a Web app just for the sake of making calls.
No, I'm just taking your argument to its logical conclusion. If you manufacture enough criteria, you can steer any discussion so that your choice is the only possible choice left. That's not how things work in reality, there are many competing factors that go into technological choices.
Minimizing round trips is an optimization with improved UX and operational cost and no real downside except marginal implementation difficulty (which itself seems like an argument for being able to share validation between the backend and frontend).
because many people wouldn't use the product or you would have to maintain multiple codebases for the various operating systems and devices (including mobile).
