7

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.

Improve this question
4
  • 3
    +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
    Commented Jan 27, 2019 at 15:26
  • 2
    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
    Commented Jan 30, 2019 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 'SO- stop being evil'
    Commented Feb 8, 2019 at 23:33
  • All you need is a function, R(p), which returns true if p is a random number. But more seriously, the whole point of PAKE is that password strength is not that important, because they cannot be brute forced in the normal way.
    – Tuntable
    Commented Jun 22, 2021 at 5:25

1 Answer 1

Reset to default
5

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.

Improve this answer
4
  • 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 'SO- stop being evil'
    Commented Feb 8, 2019 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
    Commented Feb 8, 2019 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
    Commented Mar 5, 2019 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
    Commented Mar 5, 2019 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .