[TorKlingberg]

They prefer to implement their password strength measurement server side for some reason.

Maybe they don't want to make it public by doing it it JavaScript.

Or they want to disallow reusing previous passwords, without leaking them to the client.

[arviewer]

You can use a client check to check for the basic requirements, like minimum and maximum length, characters required or allowed etc. Then when the user submits his password, you can do a serverside check.

[developer2]

The reason for using a server-side solution is for a password strength indicator. You need the full algorithm to run against the current entry, and every user-friendly implementation does this on every character input so you know when what you have typed is "strong enough". I'm not particularly a fan of password strength indicators in general, but if you're going to do it at least do it cleanly.

[czinck]

Is their algorithm so complex that it can't run in a reasonable time using client side javascript? I have trouble thinking of anything that isn't vastly over-engineered and runs slower than the network lag probably is.

[michaelt]

Perhaps their algorithm isn't written in javascript?

Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?

[ncallaway]

No, it's more about leaking information to the JS client. If, for example, their password verification rules stipulate that you can't reuse any of your last N passwords, then they would need to make this check server-side as they don't want to provide that information to the client.

[czinck]

Which sending a POST on every keystroke won't really help with anyway, because they can't tell that you typing "h-u-n" will match your old password of "hunter2", assuming it's properly hashed.

[ncallaway]

Oh, I agree. Every keystroke seems like overkill.

If I were in charge of both requirements and implementation I'd debounce the input by 300-500ms and display a "loading" spinner in the password complexity box until the debounce timer and network request had fully resolved.

I was just trying to explain why, given some business use-cases, doing password validation on the client isn't always possible.

[chris_wot]

I think an overly complex password strength checker is probably dong it wrongly. Besides, when it comes to password complexity you need to tell the end user what the rules are!

[developer2]

Combining a password strength meter with password rules is the sort of thing where most implementations are going to get it wrong. It clutters up the UI a lot, to the point of being too complicated for "average" users to understand.

I prefer seeing one system or the other, but not both.

If you have rules, don't use a password strength meter. Rules are going to be a binary result - "yes the password is good enough", or "no, this password is not acceptable" - which is represented by showing which rule(s) were not respected by the user, or a green checkmark.

A password strength meter can be used when there are no rules enforced, to let the user decide for themselves whether that red progress bar showing a weak password is good enough for their needs. The meter doesn't need to be binary, with red/orange/yellow/green stages. The only reason I don't like password strength meters in general is that there is no standard across sites/services as to what constitutes a strong password. One site will show "password123" as weak, while another will say it's fairly strong. Each implementation has its own arbitrary algorithm that is likely not representative of "true strength".

[tnorthcutt]

https://github.com/dropbox/zxcvbn

[FabHK]

This might get downvoted because it's just a link, but:

zxcvbn is actually a great password strength library, JavaScript, client-side, and only about 400 kB or so last time I checked (compressed, including (!) dictionaries). It was developed by a Dropbox engineer for the password setting/changing dialog at Dropbox, and open sourced, if I'm not mistaken.

Again, this is a great tool, client side, small (smaller than most webpages and adds these days at any rate), and it also allows to provide a list of "custom black list words" not to use in the password (e.g. username, site name, etc.).

AFAIK, zxcvbn really is the gold standard here.

Given this, I don't really see how a server-side check is better or necessary. Ebay really ought to provide a much better answer than "trust us" here.

[TorKlingberg]

You can do a lot of server round trips before you reach 400 kB.

[tnorthcutt]

What's better: A) compromising security but using less bandwidth, or B) using more bandwidth, but staying secure?

Besides, the password strength js can easily be loaded async.

[majewsky]

Yes, but these 400 kB won't contain any personal data.

[XCSme]

Yes, but why do it on the server and not on the client?

[developer2]

Why do it on the client and not on the server? It's just an implementation decision. I would never bug someone for choosing either one over the other. Most implementations probably have issues with the employed algorithm, best not to waste effort debating the delivery method.

[brokenmachine]

Or they want to disallow reusing previous passwords, without leaking them to the client.

As an aside, I have always wondered how it is possible to disallow reusing previous passwords if the password is only saved on the server as a salted hash, which is recommended I believe.

Is it possible?