khonsulabs
Reintroduce OPAQUE
-
khonsulabs/custodian#11
-
[ ] Revert 5bcb2337279bcf77960d4917fa98bbf8245368c9
-
[ ] Refactor OPAQUE handling to use the new
AuthenticationAPIs.authenticateshould return a different result when authenticating with OPAQUE, allowing for a subsequent API call to finish the authentication. -
[ ] Figure out how to deal with this conundrum: A random client shouldn't be able to determine if a username is a valid username. How does a client with no state authenticate as an existing user? How does the client determine which OPAQUE algorithm to select when sending its initial login attempt?
One potential solution would be to allow an unauthenticated client to request authentication as a user, and the server responds with a consistent response regardless of whether a user exists. That response asks for a specific form of authentication, the client then responds and can authenticate. By allowing all attempts to succeed with reproducible results, this isn't giving an attacker any extra knowledge about whether a username is valid or not.
Refs #159.
