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.
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.
Either is acceptable
A few considerations:
From a usability point of view, checking client-side has less latency, and so is more user friendly.
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.
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.
Edit in 2018 Best practice is now to check the user's password is not one of the millions that have been leaked in data breaches. This can only be done server-side.
Should user's password strength be assessed at client or at server side?
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.
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).