Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Now most of big website like Google mail, Twitter, Facebook have a feature that assesses password strength (check number of digit, alphabet, special characters, or check the similarity over already hacked passwords) for a guest while he is in a registration, but where should the assessment be processed at client side or at server side and then the server sends the assessment result to the client. In case the answer is at server side, does the server assess the password's strength over the plain text form or encrypted form of the password.

share|improve this question

Password strength, in this context, is a meaningless concept. The strength of the password, in most cases, isn't an intrinsic property of the password itself. That input validation logic in registration forms merely checks the password against a certain criteria: Does it have a number? Does it have a special character? Is it longer than 8 characters? etc.

Such checks can be done in the client's browser or on the server. Enforcing those conditions, however, can only be done on the server as the user can simply bypass those client-side restrictions. Those checks are done in the user's browser because it's much faster to do them there; they're just indicators for the user. Once the password is submitted to the server, it must be checked against those conditions.

Side note: I'm not a big fan of restrictive "password strength" conditions and I don't recommend them. However, I do see the benefit of checking for a minimum length and making sure that the password doesn't exist in a dictionary or wordlist.

share|improve this answer
+1 for pointing out that client-side checks can be bypassed. – gowenfawr Nov 17 '13 at 15:00
+1 when a password is submitted, and if the server checks it against predefined criteria, I guess that the client sends that password in plaintext because as you said that password must be checked once again by the server. Is there any risk when the server knows user's password in plaintext? – leomidu Nov 17 '13 at 16:48
@leomidu Passwords stored on the server must be securely hashed regardless of the restrictions you have on them. It is the industry standard to let the server know the plaintext password because of the implicit trust you have with the server. After all, all of your account information are already there. (note: I'm a big fan of client-side password hashing for a number of reasons. However, I don't really see that idea popularly adopted any time soon) – Adi Nov 17 '13 at 20:07

Either is acceptable

A few considerations:

  1. From a usability point of view, checking client-side has less latency, and so is more user friendly.

  2. You can do more detailed checks server-side. For example, checking if the password is based on a dictionary word. However, most sites do not do these detailed checks. In any case, I'm not convinced on the benefit of doing detailed checks. The point of checking password strength is just to deter someone using a trivially weak password, no more than that.

  3. If you do any validation client-side then a malicious user can circumvent the checks. You should normally repeat any checks on the server. However, in the case of password strength, I don't see this is important. If a user will go to the length of using a interactive proxy to allow themselves to use a weak password, then fair play to them. At that point, I'll leave them alone.

In fact, rather than a password strength checker, I favour having a password strength advisor. As the user types their password, an indicator says "weak... medium... strong". They are not forbidden from using a weak password; they are just warned.

share|improve this answer

A cursory check of Gmail indicates that the password strength analysis is done at the client side using JavaScript. I read through their .js for a little while, decided it was inpenetrable at 9:30 in the morning with no coffee, and watched the wire with tcpdump while I typed in a new password instead. Each keypress did not trigger traffic between the browser and Google, but whenever the assessment of the password changed (e.g., from 'too short' to 'weak') there was traffic correlated with the little help text bubble changing.

You can press F12 in Chrome while on their change password page and browse all their JavaScript. Drink coffee first.

That being said, in the World Wide Web passwords are almost always sent to the server in plaintext, but ideally over HTTPS so that the SSL wrapper provides security. They're either in plaintext in the form GET or POST, or they're encoded (not encrypted) in the HTTP Basic Auth header. Why? Key management.

The client has no way to key to encrypt the password that the server shares. Setting one up would either require distributing secret keys to N+1 clients and maintaining secrecy... or setting up a public key system. And once you've set up a public key system, you just kick yourself and say "Why didn't I just trust the SSL to begin with?"

Now, here's some outliers to consider:

It's possible for a server and client to perform digest authentication. In short, the server sends a random string, the client hashes the password and mashes it up with that random string and sends it back. The server needs to have a plaintext copy of the correct password on its side; it performs the same hash+mash process and compares. This is harder for an attacker to grab the password on the wire, but usually requires that the server know the plaintext password (as opposed to a hashed version).

BMC Remedy once implemented the following: The login page contained JavaScript that would scamble the password - IIRC it stored a static string and would perform a substitution cipher on the password using that string. It would send the modified string to the server, who could simply reverse the substitution. Only problem? Anybody could reverse the substitution, because it followed a static algorithm which was published in the JavaScript on the login page. So Remedy-over-HTTP provided no real protection for passwords... which goes back to the original theme, of "we generally just trust SSL to protect passwords in transit"

Finally, I'm aware of one application - Litle PayPage - which distributes JavaScript with an embedded public key. PayPage accepts not passwords but credit card data, and the JavaScript encrypts the card number with that embedded key before wrapping the entire request in SSL and submitting over HTTPS. The same could be done with any application, essentially solving the initial problem I listed of sharing keys with client - or reproducing the SSL system, take your pick. The advantage of this approach is that it sidesteps the traditional problem of "What if there are HTTP gateways that perform a MITM on SSL?"

share|improve this answer

Should user's password strength be assessed at client or at server side?


Client-side checking is very useful from a usability perspective as you can perform the check without the user sending any data to the server which will incur a latency penalty. Such checking is easily achieved using javascript in a web browser.

If you need the password strength policy to be enforced, perhaps as part of one regulation or another, the enforcement has to be done on the server side. Any client-side checking can be (relatively) trivially bypassed.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.