Slowing down attacks on compromised database

[mitar]

Section 10.8. OPRF Key Stretching explains:

that applications must consider a tradeoff between the performance of the protocol on clients (specifically low-end devices) and protection against offline attacks after a server compromise.

This is very high-level and not very instructive for how exactly can one find sweet spot in this tradeoff. Especially the issue here is that somebody integrating OPAQUE into their applications might not be savvy enough to do make this call. (I like how Ory made a script to help their integrators to determine good configuration.)

To my understanding the underlying issue here is that there is a fundamental issue with OPAQUE: because hash is computed on the client side and not on the server side, integrator of OPAQUE has much less control and even understanding of capabilities clients might have, not to mention that the diversity of client devices is higher and thus one generally has to pick the least resource intensive hash configuration for good user experience for all or most users or at least less resource intensive configuration than what one for server-side would be (e.g., mobile devices has less memory and CPU power than a server). As such it looks to me that OPAQUE already makes a trade-off and weakens offline attacks protection for protecting passwords in transit.

I feel spec is slightly misleading here. When I started reading it it looked to me like perfect combination of things: a) expensive hashing is done on the client b) no password is stored on the server in any form c) password is never send to the server. But even if password is not stored on the server in any form, server contains everything needed for (bruteforce or dictionary) attacking and trying to determine the password. OPAQUE just replaces one one-way function (hashing) with another (decryption without a key). And we generally now know how to have slow hashing functions, while decryption we generally still optimize for speed. So the only thing standing in way of how fast you can do an offline attack is the hashing configuration intended for the client.

Together with no good story on how to upgrade hashing configuration (#394) this looks to me like a pretty important downside of OPAQUE. And leaving to integrators to determine how to solve this does not feel good to me. Maybe OPAQUE is missing one more piece which would make the offline attack harder while client hashing would be what protects data in transit?

[stef]

n.b. "upgrade hashing configuration" is exactly the same problem and solution as when the user wants to upgrade their password. this is because the server is completely oblivious regarding the used password hashing algo or difficulty.

and thus an attacker who has access to a leaked database of opaque server side records, has absolutely no clue (from the opaque server records only only) which record is protected by which password hashing algo and difficulty (assuming a multitude of clients and configs here), so in this case the attacker has to guess a triple, algo/difficulty/password to succeed with an offline bruteforce attack. good luck with that :)

[mitar]

so in this case the attacker has to guess a triple, algo/difficulty/password to succeed with an offline bruteforce attack

Neat, I didn't think about that. But this is security through obscurity, so I am not sure if it counts. :-) At least for web apps, you get client code served easily. But yea, it is a nice idea.

[stef]

so in this case the attacker has to guess a triple, algo/difficulty/password to succeed with an offline bruteforce attack

Neat, I didn't think about that. But this is security through obscurity, so I am not sure if it counts. :-) At least for web apps, you get client code served easily. But yea, it is a nice idea.

well, even if you get the code for the webapp, you don't get the configuration of the user for this webapp? what if every user has their own preferences stored locally?

[chris-wood]

Sorry for the delay, @mitar! And thanks for filing the issue. The complete text in Section 10.8 reads:

Applying a key stretching function to the output of the OPRF greatly increases the cost of an offline attack upon the compromise of the credential file at the server. Applications SHOULD select parameters that balance cost and complexity. Note that in OPAQUE, the key stretching function is executed by the client, as opposed to the server. This means that applications must consider a tradeoff between the performance of the protocol on clients (specifically low-end devices) and protection against offline attacks after a server compromise.

While this doesn't exactly say how key stretching parameters ought to be chosen, it does seem to make the tradeoff clear.

Are you asking for clarity on how the parameters ought to be chosen, perhaps by pointing to common examples? Or maybe you're asking for additional text about how this tradeoff is unique to OPAQUE compared to other password hashing scenarios? Do you have suggested text you might add?

[chris-wood]

@mitar we're going to close this in the absence of concrete suggestions on how to make the tradeoff. Please feel free to reopen if you feel strongly that something should be done here, and ideally if you also have something specific to add, change, or remove!