OPAQUE passwords

[kurnevsky]

I see that rauthy is accepting passwords in a plaintext form and then stores their hashes. It's possible to improve it using zero-knowledge proofs instead. Have you considered using OPAQUE? As an example it's implemented in lldap.

[sebadob]

Thought about something like that, but quickly threw that idea away. It does not bring any real advantage or improvement, while only coming with quite a few drawbacks. It makes sense for situations with unencrypted connections, but for Rauthy I don't see any real advantage.

• Rauthy only works over encrypted connections (apart from localhost for testing)
• All structs that may contain sensitive information either have no Debug impl at all, or have a custom one which redacts all secrets, which means no leaks in logs.
• Rauthy never does such silly thing as caching clear text passwords
• Everything is hashed with Argon2ID with such high defaults, that make it impossible to ever brute force a password, as long as your password is not 12345678 or something like that (opaque does not protect you in that case either)
• Cleartext passwords are being zeroized in memory after hash comparison
• There is absolutely no issue with Rauthy knowing your plaintext password. If you don't trust the service you are using, you should not be using it at all in the first place. Actually, if Rauthy would not be able to see your plaintext password, you would lose features like e.g. being able to apply a password policy. This would have the exact opposite effect and weaken your security instead of hardening it.

This leaves an attacker with only a single attack vector: Gaining full root access to your underlying host and trying to read cleartext passwords from memory, before they are overwritten with zeros, which is way harder than it sounds because of various protections mechanisms enabled in every kernel or even hardware by default. But the thing is, if someone became root on your host, you are screwed anyway. Why should an attacker go the super hard route trying to read some password in microseconds from a randomized memory location, when he could also just start up a modified instance of the service that logs each password into a file?
Being root is also the only way how you could extract Argon2ID hashes from the DB, which you then will never be able to crack anyway. Breaches that lack passwords from DB happen usually because of sqli vulnerabilities, which cannot happen with Rauthy as well, because it uses prepared statements exclusively.

The problems that come with something like OPAQUE though are things like a lot more complicated password registration + login ceremony, afaik not even being able to rotate your backend secret if it leaks, because you would not be able to validate all already registered passwords anymore, it's not standardized in any way and does not bring native browser support. It would also make any custom implementations for Rauthy way harder, when it would not accept plain passwords. On top of it the already mentioned degradation of security because you would not be able to apply a password policy to make sure the user uses actually secure passwords. OPAQUE allows a user to set 1234 as password and the server would not have any way to validate properly, that it's secure.

Using OPAQUE though has the exact same attack vectors as the current approach has, with the exception that an attacker theoretically could not read a plain password from a randomized memory location while being root, which he would never do in such a situation anyway, because it's literally the way of most resistance.

So in the end, the only difference is, that Rauthy would not see your password. That's it. But here is the thing: If Rauthy (or any other application) would have malicious intent, it doesn't even need to know your password. It has the JWKS to generate as many tokens as it wants and use them to authenticate against downstream clients until end of time.

Solution

The solution to all of this is super easy and exists already: Webauthn

Just use a passkey, and maybe even remove the password completely from your account, or don't register one in the first place. This brings only advantages without any downsides. Why trying to fix passwords and make them a lot more complicated, when we already have a way better, standardized solution with browser-native support in every way?

[kurnevsky]

Thanks for the detailed response!

All structs that may contain sensitive information either have no Debug impl at all, or have a custom one which redacts all secrets, which means no leaks in logs.
Rauthy never does such silly thing as caching clear text passwords

This is prone to a developer mistake. Nobody intentionally does such silly things, but in practice this still might happen, and OPAQUE protects from such mistakes.

Actually, if Rauthy would not be able to see your plaintext password, you would lose features like e.g. being able to apply a password policy.

You can implement this policy on a client side, you don't really need to enforce it in the server. And if users intentionally decide to bypass it manipulating requests, well, that's their decision and their responsibility.

This leaves an attacker with only a single attack vector: Gaining full root access to your underlying host and trying to read cleartext passwords from memory, before they are overwritten with zeros, which is way harder than it sounds because of various protections mechanisms enabled in every kernel or even hardware by default.

Recently there were a lot of hardware vulnerabilities that allowed to read arbitrary memory locations. Also who knows who can read memory of your virtual machine if you are hosting on VPS. OPAQUE protects against passive attacks which are theoretically easier to perform than active attacks.

afaik not even being able to rotate your backend secret if it leaks, because you would not be able to validate all already registered passwords anymore

You should still be able to validate it, clients don't persist any secret values besides passwords on their side, so knowing a leaked password you can check if it matches stored by server secrets.

It would also make any custom implementations for Rauthy way harder, when it would not accept plain passwords.

Is there a goal to make it easy? Rauthy already has custom proof of work implementation anyway.

Why trying to fix passwords and make them a lot more complicated, when we already have a way better, standardized solution with browser-native support in every way?

Not everyone might want to use it. There are people who might prefer using stateless hashing password manager like LessPass, or not use password manager and physical keys at all. And I don't think enforcing everyone to use passkeys is the way to go. So making passwords more secure is still a good thing, considering that Rauthy allows to use only passwords.

The only real drawback of OPAQUE is that as a user you don't really have a good way to make sure it's actually used, so you can't really rely on the fact that server will never get your password without inspecting the client code that you get from the server each time you log in. I think OPAQUE is still an improvement over a traditional schema, but I guess it's fine if you already considered it and decided it's not worth to be implemented.

[sebadob]

You can implement this policy on a client side, you don't really need to enforce it in the server.

Things like this can very easily create huge issues. I only do validation on the client side to provide an improved UX but never to actually enforce or truly validate anything.

And if users intentionally decide to bypass it manipulating requests, well, that's their decision and their responsibility.

Not really, it depends. For instance when you must follow policies that are given from a higher instance, or maybe even by law, which is the case in a lot of situations here in the EU. When the server does not enforce a password policy, you just cannot guarantee that all users are following it. That's actually one of the biggest issues with it and it can get you in some serious trouble.

Recently there were a lot of hardware vulnerabilities that allowed to read arbitrary memory locations. Also who knows who can read memory of your virtual machine if you are hosting on VPS.

Yes, true, but the problem for an attacker is the same as described above. Servers usually not only encrypt memory, but memory locations are randomized. Even if you would know, where you need to look for a plaintext password that only exsits for a very short amount of time, it's still the way of the most resistance. You could also just read out JWKS and use it as a "master key" to generate as many tokens as you like. Why bother with some random users password?
Tbh, when you have an attacker in your OS on such a low level, there is no way that you can really protect yourself from it, because the attack surface is huge.

You should still be able to validate it, clients don't persist any secret values besides passwords on their side, so knowing a leaked password you can check if it matches stored by server secrets.

Only if you also keep the leaked secret around and use it for the validation, as far as I understood it. And if this is the case, to be able to rotate secrets, you also need additional overhead and track the secrets you used for all the server side contexts. It's just such a big overhead and disadvantages for such a tiny improvement.

Is there a goal to make it easy? Rauthy already has custom proof of work implementation anyway.

Well, yes and no. I mean, yes it should be as easy as possible, but not without sacrificing security. The PoW should be pretty easy to use for anyone. I even kept the UI in Javascript instead of going Rust + WASM so people can copy & paste most of it if necessary. I at least try to make everything as easily usable as possible, but it's always a compromise between security an ease of use and I don't really make compromises in terms of security.

OPAQUE just is not worth it to me. You gain not having a plain text password in randomized and often even encrypted memory, but you pay with so much. The biggest issue in the end is not being able to enforce a password policy.

And I don't think enforcing everyone to use passkeys is the way to go.

Rauthy is not doing that. If you don't like passkeys for whatever reason, you can use passwords. As long as you use a proper password manager and follow reasonable rules, they are pretty secure.

The only real drawback of OPAQUE is that as a user you don't really have a good way to make sure it's actually used, so you can't really rely on the fact that server will never get your password without inspecting the client code that you get from the server each time you log in.

Yeah that's another thing. I mean, a normal user should never even have to worry about such things anyway. If it's client side only, you could of course just read the source code of the UI and you would know. But what do you gain from this? A password should never be used for multiple logins anyway, if you actually care about security. So the worst thing that could happen, is that the app you want to use, knows your password, that you don't use anywhere else. So in the end, it cannot do anything with it.

I think OPAQUE is still an improvement over a traditional schema

Don't get me wrong, it absolutely is and I always prefer such solutions. It still has some issues like the password policy, but I would not even know how to solve this one without inspecting the plaintext password. Not sure if there would be a solution how it could be achieved, maybe with even more Pkey crypto and the UI "verifying" that it inspected the password, but not sure how to prevent spoofing it then if the code is public in the first place. I think it would only be possible if you "trust" the user, but that's a very bad idea.

[kurnevsky]

For instance when you must follow policies that are given from a higher instance, or maybe even by law, which is the case in a lot of situations here in the EU.

I'm not an expert, but I have a suspicion that client side enforcement should be enough to comply with the law.

Why bother with some random users password?

A lot of people reuse their passwords on different platforms, regardless how bad it is. So for attackers it will still be beneficial to learn user passwords. OPAQUE would protect against passive attacks, but in case of active attack it's just possible to inject a tracker in the UI.

Only if you also keep the leaked secret around and use it for the validation, as far as I understood it.

All secrets are stored on the server side, clients know only their passwords, otherwise it wouldn't be possible to log in with a password from a completely clean environment. So knowing leaked passwords server should be able to verify that these passwords belong to user accounts, just by executing OPAQUE protocol instead of a client.

I think it would only be possible if you "trust" the user, but that's a very bad idea.

Why would anyone try to hack the UI just to make their password weaker anyway? :)