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.
Asked
Active
Viewed 6,707 times
5 Answers
16
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.
-
4+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](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) 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
-
I was with you until this: "making sure that the password doesn't exist in a dictionary or wordlist.". This rules out diceware-style passwords, which are perfectly reasonable. According to the latest NIST best-practices (which I agree with) instead of checking against a word list you should check against a list of previously-leaked passwords. haveibeenpwned has a service for exactly that. Don't check against a word list. Limiting your users to gibberish passwords only hurts them in the long-run. – Conor Mancone Nov 07 '18 at 14:54
-
@ConorMancone You should always check against a wordlist because even the international wordlist of all words in all languages is only 1.5 million which a brute force engine will typically check against within the first few seconds, so you should check for both. That said, combinations of words like "FastRedSpeedBoat" are very hard for dictionary attacks to crack because every word exponentially increases difficulty; so, even if you are going off of a simpler 60k word English list, you still have the same complexity as a truly random 10 character password. – Nosajimiki Nov 07 '18 at 15:28
-
@Nosajimiki yes, your last sentence is exactly my point. For passwords that are the combination of a 6-10 random english words (aka diceware) you have a very strong password that is also easy-to-remember (easier anyway). However, any password checker that checks a word list will find a match and refuse what is, in fact, a good password by *all* measures. Having had word list checks reject my very strong diceware passwords, it is irritating. Don't check a word list. Check a leaked-password list. – Conor Mancone Nov 07 '18 at 15:33
-
^sorry, the above password would be that strong in all lowercase. Casemixing makes it stronger, and random case mixing it like "fAstRedSpeeDbOat" would make it intractable as a dictionary target and make it's only real vulnerabilities traditional brute force or leaked lists. And as a true brute force, 20 characters long can pretty much resist anything you throw at it; so, it's unlikely to be exposed even if there is a hash leak. – Nosajimiki Nov 07 '18 at 15:34
-
1Ah, that must have been a bad implementation case then (I saw some of those a few years back too). You should check against plain words, not the inclusion of words. – Nosajimiki Nov 07 '18 at 15:36
-
1@ConorMancone I apologise if my answer caused you to conclude that I'm recommending prohibiting diceware-style passwords. I hoped the intention was clear; to check if the whole password is a single word in the dictionary. I'll try to reword such recommendation in the future to avoid this confusion. – Adi Nov 11 '18 at 16:10
8
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.
paj28
- 32,736
- 8
- 92
- 130
-
1can you point to a source of password leaks? I cannot find, everyone thinks it is kind of an artifact and don't publish such crap as raw leaked passwords. – Croll Nov 07 '18 at 13:10
-
1
-
Big supporter of the "password strength advisor", since some schemas are secure in practice, but not in theory. – Nosajimiki Nov 07 '18 at 15:41
4
Should user's password strength be assessed at client or at server side?
Both.
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.
3
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?"
gowenfawr
- 71,975
- 17
- 161
- 198
0
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).
