checking of password strength

[stef]

the section Password Salt and Storage Implications says the following:

Some applications may require learning the client's password for enforcing password rules. Doing so invalidates this important security property of OPAQUE and is NOT RECOMMENDED.

i agree that this is not a good thing, and also should not be recommended, but maybe caveat this, with "depending on threat model, for example internal corporate deployments are possible exceptions were enforcement of strong password policies is mandated by regulation"

Applications should move such checks to the client.

"malicious" clients can easily ignore password rules, and the server will never know about this. This can be a problem when corporate rules mandate strong passwords, but users want to circumvent this for whatever reason (mostly lazyness?) - this is well known rule in application security that the server should never trust any input validation by the client.

Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change.

i wonder how this would work, can someone enlighten me?

[odiferousmint]

Applications should move such checks to the client.

"malicious" clients can easily ignore password rules, and the server will never know about this. This can be a problem when corporate rules mandate strong passwords, but users want to circumvent this for whatever reason (mostly lazyness?) - this is well known rule in application security that the server should never trust any input validation by the client.

Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change.

i wonder how this would work, can someone enlighten me?

I have not finished reading the document, but I assume that we can tell whether the password is the same or not (as it was on the initial registration) based on the data associated with the client that we store (such as Opaque_UserRecord[1]). Either way, supposedly the server may store information related to the client that should make us able to tell that the password has either remained the same (repeated password, theoretically could keep a counter per registration), or that it is different (password change).

Pre-define TRACE when compiling, and then perform the registration at least three times (two identical, one different password) and then you will gain more insight as to what has changed and what did not change and when.

[1] https://github.com/stef/libopaque/blob/master/src/opaque.c#L61 tells me that Opaque_UserRecord may definitely be stored at the server upon registration. I assume - depending on what they claimed - that at least one of those values remains the same across registrations as long as the password is the same.

---

server should never trust any input validation by the client.

In many cases it is true, the server must have its own checks, be it for input validation or whatever else. That said, as per specification, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. Ultimately it is up to the application whether or not it wants the password, but I believe it would defeat the purpose of using OPAQUE to begin with.

[stef]

ah, the the mac of the envelope will not change if nothing (even the password - password reuse) changes on re-registration. if the prf key is not changed. but 1/ reregistration itself is not well specified and 2/ i think how and where prf key comes from in such a case is neither, i do not think its a good idea to not change the prf key on reregistration.

[odiferousmint]

ah, the the mac of the envelope will not change if nothing (even the password - password reuse) changes on re-registration. if the prf key is not changed. but 1/ reregistration itself is not well specified and 2/ i think how and where prf key comes from in such a case is neither, i do not think its a good idea to not change the prf key on reregistration.

Yeah, I do not know if it is supposed to NOT change, but I do not like the idea of it not changing, to be honest.

[kevinlewi]

Regarding the enforcement of strong password policies because it is mandated by regulation: I agree that this is to some extent in conflict with OPAQUE, because it fundamentally does not allow the server to perform these password checks server-side. In fact, I feel like if it is absolutely required for these server-side checks to be done on the password, then OPAQUE should not be used. Therefore, I feel like the wording should stay as-is, without the caveat.

(However, in practice, I feel like doing client-side checks should still suffice. Perhaps this is dependent on the regulation, but I feel like if a client is specifically trying to get around client-side checks to make a weaker password, then this is the client's fault, not the server's. But that's just my opinion of course :) )

Some other comments:

1. Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change. This would work by essentially simulating the login mechanism using the old record with the server and checking if it succeeds. Note that it requires the client to be honest and report the success, which in my opinion is sufficient, but perhaps if there are regulations which mandate this to be foolproof, would not suffice.
2. I am not sure I am understanding, but the MAC will indeed change if the password is re-used upon re-registration. This is because, at the very least envelope_nonce gets sampled randomly. To be clear, upon re-registration, we should be completely clearing the old record, and re-running all of the procedures for envelope creation from scratch. Ok, fair enough, if the client chooses to remember these nonces and re-use them during re-registration, then they would be leaking information to the server about this. But again this is an instance of a client shooting themselves in the foot.

[stef]

Regarding the enforcement of strong password policies because it is mandated by regulation: I agree that this is to some extent in conflict with OPAQUE,
because it fundamentally does not allow the server to perform these password checks server-side.

uhm, but the original paper provides exactly such a registration function and mentions it even that the password strength can be checked using this approach. to say "fundamentally does not allow" is in direct contradiction with the original paper.

In fact, I feel like if it is absolutely required for these server-side checks to be done on the password, then OPAQUE should not be used. Therefore, I feel like the wording should stay as-is, without the caveat.

i think even if the one-shot registration of the paper is implemented, and the password is exposed once to the server, the other benefits and security guarantees of opaque make it still the best solution otherwise.

so i would like to insist to have this wording changed and acknowledged that there are other use-cases.

[kevinlewi]

@stef: Oh interesting, do you have a reference to where in the original OPAQUE paper this is explained? I am looking at the top of page 48 of https://eprint.iacr.org/2018/163.pdf:

"Note that this prevents S from checking password
rules, an operation that can be moved to the client side (restricted server-side
checks such as preventing the repeat of a recent password can be implemented)."

Is there wording elsewhere in the paper that indicates that these password strength checks can be done server-side?

Also, can you offer a suggested PR / change to the text to address your concern? IMO the "NOT RECOMMENDED" wording implicitly carries a caveat that applications may have different requirements and doesn't enforce that the application can't do these password checks on the server's side already.

[stef]

I've been looking at previous versions of the paper (since also my local copy has a bit different wording) and found that the section you quoted previously said:

A problem arises with this approach if S’s policy is to check the user’s password for compliance with some rules.

i must admit i remember something more explicit on this topic. but can't find it myself, but knowing that Hugo likes to have multiple papers on the same topic, it might be that my confusion comes from one of his other papers...

i'll try to draft a proposal that caveats the contended fragment.

[bbeallo12]

After reading this thread, I have a question.
Would there be a way for the client to cryptographically prove to the server it hasn't been tampered with in a way only the genuine client could do?

[bbeallo12]

Also doesn't the existence of 2FA make the password complexity issue a non-issue? If the password is guessed, they still need the 2FA. At which point the user is notified of the attempted login and can easily change their password.

If you also require a new 2FA token along with the password change, doesn't that make it even better?

[stef]

Also doesn't the existence of 2FA make the password complexity issue a non-issue? If the password is guessed, they still need the 2FA. At which point the user is notified of the attempted login and can easily change their password.

If you also require a new 2FA token along with the password change, doesn't that make it even better?

OPAQUE is essentially and AKE, and has nothing to do with 2FA, OPAQUE can be part of a 2FA scheme, but that is only one use of an AKE, in other settings where OPAQUE is used to derive a key for an encrypted channel or for retrieving some encrypted blob, there is no 2FA and thus password strength does matter. Futhermore password strength also matters (although not in the enterprise setting) because a server (or someone who has the server records) can just offline brute force the password, and thus even then password strength matters and 2FA is irrelevant.

re: #434 (comment) - clients can prove correctness using attestation, and that is a brittle concept or it leads to a bad DRM dystopia, on phones this is a bit easier, apple and windows might be able to pull this off, but uefi/secureboot is really a broken concept, so it is quite impossible to do so reliably on desktops.

[bbeallo12]

Also doesn't the existence of 2FA make the password complexity issue a non-issue? If the password is guessed, they still need the 2FA. At which point the user is notified of the attempted login and can easily change their password.
If you also require a new 2FA token along with the password change, doesn't that make it even better?

OPAQUE is essentially and AKE, and has nothing to do with 2FA, OPAQUE can be part of a 2FA scheme, but that is only one use of an AKE, in other settings where OPAQUE is used to derive a key for an encrypted channel or for retrieving some encrypted blob, there is no 2FA and thus password strength does matter. Futhermore password strength also matters (although not in the enterprise setting) because a server (or someone who has the server records) can just offline brute force the password, and thus even then password strength matters and 2FA is irrelevant.

re: #434 (comment) - clients can prove correctness using attestation, and that is a brittle concept or it leads to a bad DRM dystopia, on phones this is a bit easier, apple and windows might be able to pull this off, but uefi/secureboot is really a broken concept, so it is quite impossible to do so reliably on desktops.

Doesn't that make the assumption you're using OPAQUE in a vacuum? Why not use it together with multiple authentication methods?

As for attestation, so it isn't an issue of possibility but more an issue of the potential implications.

[stef]

you are reducing OPAQUE to an auth mechanism, instead of considering it an AKE. for an auth mechanism this makes sense, but for an AKE not.

[bbeallo12]

you are reducing OPAQUE to an auth mechanism, instead of considering it an AKE. for an auth mechanism this makes sense, but for an AKE not.

Ah okay, that makes sense. Thanks for explaining that.

What if hypothetically there could be a zero knowledge proof algorithm that can prove to a server the password was generated using the required complexity requirements without sharing the actual password. If such an algorithm could exist, would that resolve the issue?

[kevinlewi]

@bbeallo12 Yes, hypothetically that would resolve the issue. However, the issue is that these ZK proofs are expensive, and it would have to be custom-tailored to the password complexity rules. Either way, out of scope for the draft work here (since in the future if one does pursue that path, it could be sent to the server in addition to the OPAQUE messages).

Closing this issue since #437 was merged

[cyyynthia]

I'll just add this resource I stumbled across a while ago while researching this myself that might interest people reading this thread; some people have been working on zero-knowledge password policy check protocols, although they are currently impractical. They do exist, though, so there's hope they'll become more practical soon!

• Kiefer, F., Manulis, M. (2014). Zero-Knowledge Password Policy Checks and Verifier-Based PAKE. In: Kutyłowski, M., Vaidya, J. (eds) Computer Security - ESORICS 2014. ESORICS 2014. Lecture Notes in Computer Science, vol 8713. Springer, Cham. https://doi.org/10.1007/978-3-319-11212-1_17
• Nguyen, K., Tan, B.H.M., Wang, H. (2017). Zero-Knowledge Password Policy Check from Lattices. In: Nguyen, P., Zhou, J. (eds) Information Security. ISC 2017. Lecture Notes in Computer Science(), vol 10599. Springer, Cham. https://doi.org/10.1007/978-3-319-69659-1_6