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).
Depends on what you want to accomplish.
Client-side, checking has the feature of a strong recommendation. If you disallow form submission with a "weak" (whatever your definition, that's a whole other discussion) password, 99.9% of users will pick something that follows whatever guidelines you put up, and a tiny percentage will mess with your form and bypass the check.
On the plus side, you get immediate, live feedback, users can see their password "strength" while typing it, knowing when to stop (e.g. when the bar turns green).
Server-side, you can do more extensive checking and really enforce it. The main advantage is that you can check against a large database of known-weak or known-compromised passwords. The last is the biggest gain - you can protect your users from picking a password that is already associated with that e-mail from another breach somewhere else. 1
If you are interested in your users having good passwords, you can enter the whole discussion about what a good password is - but the best and least you can do for them is stop them from (re-)using a password that is already compromised, where the whole "password strength" discussion is already pointless.
There are probably libraries that actually interface with haveibeenpwned or similar sites, client-side, which for a public Web-App could be an alternative, but with a performance impact. I believe this kind of checking will probably work better server-side and most importantly, you can enforce password controls there. Client-side controls can always be bypassed, though only a small fraction of users will have the ability and energy to do it.
(1) I recommend against telling them that their password is already compromised, even though that would make total sense - but most users won't understand where you got that information and might even misunderstand the whole thing and believe you cracked their password and broke into their other account(s).