SRP is just a challenge-response thing that means the server can verify the users password, without having the actual password (or hash representation of the password). As such it's kinda nifty idea to use that in Keycloak.

Implementation wise it's probably something that can be POC relatively easily with a custom authenticator and custom credential type in Keycloak. You'd of course need some JavaScript added to the client-side, which the authenticator can do.

I tend to disagree with the man in the middle attack being all that valid here. End-to-end TLS takes care of that just fine. If anyone are able to intercept the users passwords with a mitm they can just as well sniff tokens instead, so proper TLS is a must regardless.

Rather the real thing this would add additional protection against is ability to obtain users passwords if the Keycloak server or its database is compromised. It does rely on users reusing the same password cross multiple services to be useful though. However, there are other things that protect against that. Not re-using passwords cross different services is one, two-factor authentication another, WebAuthN is a great one (as it basically is similar to SRP with it being a challenge-response thing, but compared to SRP significantly stronger as it doesn't rely on potentially short/bad passwords).

So, all in all I'm not all that convinced if this stuff is needed.

@stianst while I agree with what you say, your suggestion rely mostly on the users doing the right thing. I learned this is the hardest thing and it does not work if you have less tech savvy users. I believe the platform should to everything to keep it simple and secure for the users. Which is why I would love to see SRP or an equivalent in keycloak.

@stianst SRP (Secure Remote Password protocol) is designed for a different threat model. In real production environments, end-to-end TLS usually terminates at the API Gateway (e.g., NGINX). From there, the password might pass through multiple intermediary nodes before reaching the Keycloak service, which increases the attack surface. If any of these nodes are compromised, there is a risk of password leakage.

SRP addresses this threat model effectively. Even if intermediary nodes are compromised, an attacker still cannot retrieve the actual password.

While the different threat model exists and some form of Asymmetric/Argumented Password-Authenticated Key Exchange (aPAKE) protocols like SRP can help with it, I personally still wouldn't add support for SRP.

(Disclaimer: I'm at best a security aware software engineer, not a security researcher or cryptographer)

A non exhaustive lists of issues with SRP:

• even through SRP is kinda old and seems simple the degree of proven security guarantees compared to other aPAKEs is surprisingly limited
• there are better alternatives e.g. OPAQUE
• SRP might not fix your thread model even if it might look like it initially
  • e.g. the H(salt, password) send during registration is basically like a "high entropy password" anyone who gets it can impersonate the client and snoop on conversations encrypted with the SRP derived key. This means if you thread model was "what if someone can read the communication between web gateway and server" it isn't really fully fixed by SRP. Sure they don't get the password only the hash, but you also never get the password only auth based on the hash => so the hash is the password.
  • also I might be missing something but in difference to more modern aPAKEs liek OPAQUE, SRP seems to be missing a non-ephemeral server key, I'm not fully sure about the exact consequences but it should make impersonating the server way easier (in context of having "seen" the registration procedure and/or MITM the registration procedure)
  • if you thread model full E2EE between client and backend services accessed by request first passing through other services (e.g. web gateway), things get supper complicated, SRP (or any aPAKE) will not safe you here at all

all in all this means even if Keycloak would implement an aPAKE for password login, it probably would not be SRP

but there is a much bigger problem with Keycloak and aPAKE in general

• the idea of aPAKE isn't just login, but to produce a shared secret you then use for encrypting a communication channel
  • as consequence you normally want to run the aPAKE between the client and server which do actually communicate for the non-login interaction i.e. in OIDC terms the relying party (client) and resource server (i.e. not Keycloak)
  • i.e. aPAKE would replace the Authroization: Bearer <access_token> part in resource servers but that means it really doesn't work that well any of: SSO, OIDC, OAuth2
  • but "SSO, OIDC, OAuth2" is kinda the main point of Keycloak 😅

and if using a aPAKE only for login but not key exhange then the go to solution this is competing with for "having some MITM/snooping protections on login" seems to have become passkeys, even if I don't like the direction they developed into 😞

now to be clear the idea of not even sending password so that no one can snoop on it still is nice

What would be your point of view in regards to a Vault use case, where there is a requirement for Zero Knowledge where the provider must not know the password or the secret key to decrypt the vault?