[pphysch]

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.

[zamadatix]

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.

[pphysch]

You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".

[zamadatix]

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?

[Dylan16807]

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.

[zamadatix]

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

  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.

[Dylan16807]

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.

[obpe]

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.

[yawaramin]

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

[zamadatix]

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.

[yawaramin]

If you Google 'password strength' the first result is https://www.passwordmonster.com/

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.