4

Can a password strength policy i.e.: must contain at-least 8 chars must contain one uppercase letter must contain one lowercase letter must contain one number

Be enforced if a PAKE protocol is used, such as OPAQUE? Is there any way with these protocols (eg, OPAQUE) to prove the password conforms to the above. As with PAKE the password never reaches the server, and client side checks can be easily bypassed. Does this mean with PAKE that users could use passwords with 3 or 4 characters (or lower, of course)?

I know I can check against commonly used passwords & specific passwords, such as historic user passwords, by encrypting and comparing outputs. But of course it is not feasible to check the output of every password combination up to 8 characters.

I want to check only the historic passwords & common passwords that conform to this policy.

Is there any-way on the server side to prove that the input on the client side conforms, with a protocol like OPAQUE? Given that the password is never actually seen by the server.

Does this mean the use of PAKE such as OPAQUE could potentially reduce password security?

EDIT: I am aware that enforcing minimum character requirements (eg: one number, etc) is contested. The above policy is merely an exmaple.

  • 1
    +1 for a good question. Though I feel the need to point out that "one upper, one lower, one number" is an outdated way of thinking about password strength (*God, that's so 1995!*). Please see NIST SP800-53 or a password-strength meter like zxcvbn for a more modern "entropy-based" way of thinking about password strength. – Mike Ounsworth Jan 27 at 15:26
  • 1
    There is no way of truly checking if passwords are secure. For one, I can generate a random password and then use it for multiple services or even publish it without you knowing about it. For that reason, I don't think these kind of protocols are required to test password strength. The application on which the password is entered can be used for that. If anybody wants to skip that password check and make their own data insecure, then I guess they are welcome to do so. – Maarten Bodewes Jan 30 at 2:11
  • @MikeOunsworth SP800-53 doesn't say what makes a good password, it's a lot higher-level than this (basically it says that password requirements are one of the potential aspects of a security policy). SP800-63B is the recent guidance on passwords, specifically §5 and appendix A. – Gilles Feb 8 at 23:33
3

No, you can't enforce a client-side policy via technical means. As you mention, any limits you bake into an implementation could be bypassed by someone using a modified client. But that presumes you have at least some users intent on using specially weakened clients, which seems unusual. What reasons would your users have for avoiding your official client?

While you can't stop someone from doing an end-run around your system, you could use the policy stick to require people to use only approved clients. You could audit their systems to make sure they have the official client installed. You could use technical means such as code signing, application white listing, virus scanning, and/or file integrity monitoring to help ensure they don't install rogue clients. If you find they're using an external website to do things like generate and exchange keys, add the website to your firewall's blacklist. Make doing the wrong thing harder.

Perhaps you could require them to manage those specific passwords only from a bastion host running behind a firewall. The bastion hosts would be locked down and used only for those particular security operations, then any exchanged passwords would be copied back out to the client. I'm not saying it's the most secure choice, only that it's potentially another way of controlling the users' behavior. Similarly, you could provide a wrapper service in front of the PAKE system and use the wrapper to test for password conformity. Of course, these approaches leave you with a bastion host or wrapper service that you have to secure, manage, and inspect, which could be a bigger and more expensive headache.

Sometimes all you can do is state your policy (and the scary penalties for non-compliance) and expect people to follow it. Consider a policy-only approach until it's alleged (or proven) that users are circumventing it.

  • You should clarify that this answer applies to OPAQUE, but it doesn't apply to all PAKE mechanism. With “basic” PAKE, the server knows the password, so it can apply whatever controls it likes at password choice time. It's only with augmented PAKE that the server doesn't know the password. – Gilles Feb 8 at 23:38
  • @Gilles , I read into his question that he was interested in the security implications of various client based password exchange mechanisms and protocols, not just OPAQUE. Perhaps I read too much into it. – John Deters Feb 8 at 23:52
  • It is not a real problem, if a user wants to bypass these restrictions willingly then yes you are right that is their own pitfall. --- The question was more concerned on the technical aspect, if there was any crypto/maths magic that would allow this. I ask because of course although in this case I can't see any major problems from this, it is never ideal to have unintended & unverified input. The only issue, which I am fine to deal with, would be malicious (i.e. somebody has modified users passwords so that they cannot enter them when logging in). – Reality Mar 5 at 21:35
  • In this case I think it is ok that there is this mismatch between the client & the server. The malicious probability is so slim, other attacks are easier & more lucrative for attackers, this attack has no real use case other than proof of concept, and I have policies to deal with such malicious attempts anyway, so it is mitigated by existing policies. All I really wanted was a clarification that there was no maths proof magic you could do without knowing the password. I want PAKE - OPAQUE as I do not want the password(cleartext) ever to be transmitted from the client. – Reality Mar 5 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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