Code-server argon2 Hash requirements.

[antofthy]

In a kuberneties environment where I will be running multiple code-server containers (one per user)
I have created a ingress 'overlay' for the code-server "/login" which (after confirming the users identification against our OAuth2 server) grabs the password for the user's code-server, hashing it, and sets it has the users code-server-session cookie, before returning the to code-server proper. This IS working and means we can set ANY authentication system we like (SSO in our case, so users often are already authenticated!)

This has works very well, though I find that code-server has some very specific 'requirements' for the argon2 has it requires.
Too low a iteration, parallelism, or memory and it just rejects it provided hash cookie, redirecting back to the "/login" web overlay, so as to try again. (and getting into a redirect loop, until browser breaks it!)

Unfortunate the "Go" language argon hash is woefully bad, in that it has no clean error handling and just CRASHES the program if it can't get the resources to hash the users password! This sets upper bounds on the argon2 hashing parameters we can use.

THE QUESTION: What exactly is the requirements code-server has for an acceptable argon2 hash?

Alternative (and this is not as good, as the hash become static until environment is restarted)
Is their a way to get code-server to provide an acceptable hash instead of having the hash or some other session cookie?

is the password repeat failure limits saved to disk? If so where?

[code-asher]

What exactly is the requirements code-server has for an acceptable argon2 hash

We are calling out to the package without any arguments so it uses whatever defaults they have configured. They say the defaults are "according to the security recommendations by the team that develops Argon2" and you can see them here: https://github.com/ranisalt/node-argon2/wiki/Options.

Is their a way to get code-server to provide an acceptable hash

It might be a good idea to add a way to have code-server take your password and spit out the hash (similar to htpasswd), is that what you mean? Then as part of the setup you could have it output the right hash for the password you generated and you use that in the cookie.

I wonder though if you really need to use the hashed password and could use a plain text one instead? If an attacker gains access to the password file, they already have access to the container, and if the passwords are unique they have no further utility. There could be an angle I am not seeing though.

Is the password repeat failure limits saved to disk

No, the rate limiting is purely in memory.

[code-asher]

Also, it might be better to have an authenticating system outside of code-server, and forgo code-server's cookie altogether. Sounds like you might already have the infrastructure to make that happen, but maybe there are complications that are forcing you to do this hybrid auth setup.

[antofthy]

Their will be a LOT of users each running a container with code-server and an apache webserver.
The users are also, in general, already authenticated against a Single-Sign on system we use. We already know who they are.

Previously we were creating the container and assigning a random password that we give to the authenticated user, for them to copy-n-paste so as to login to code-server. That system has been in use for more than 5 years, in a docker environment.

Now we are migrating to a kuberneties system, and want to simply pick up the already generated password (from the code-server config file) set the session cookie, and direct them to code-server. No more copy-n-pasting. They just go to their environemnt,
If they don't have a session cookie, code-server jumps to "/login" which is overlays by our auth system. They are authenticated (often already done), and teh sesstion cookie set and sent back to code-server top level (just as the "/login" sub-system of code-server does).

Users never actually need to know their code-server password! They just login to our systems as normal (if not already), and they have access to their code-server (and no one elses).

The weird thing is that while code-server accepts the hash we create from the password most of the time. (It verifies against the password).

But when it doesn't, though, it jumps back to the '/login' sub-path which creates a new hash of their password and sends them back to code-server top-level.

What is happening is that sometimes the hash created just does not work. All new hashes of the password in the code-server config also do does not work! Endless browser re-direction look.

At first I thought the cookie was being reset and lost. But it is still present when the users browser is redirected back to our auth system, so its not being lost.

Then I thought it was the argon2 params being checked, and found to not be good enough. (Thus this request)
Well I have resolved that problem, and am now using the same params code-server uses. $argon2id$v=19$m=20480,t=3,p=2$

Now I got the feeling that the code-server internally has a different password to what it had written in its config file.
OR it is in some sort of "I am not accepting anything anymore" mode.

Basically the hashed password I set the cookie to, is either accepted first time,
OR no matter now many times I give it a hashed copy of the password as a session-cookie, it gets rejected.

And yes The system would be a LOT simpler if the session cookie was simply the code-server generated password
it saves in the config file. I actually destroy that file everytime code-server is restarted, so a new one is generated on startup.
It should not matter what that password is. The User never needs to know what it is.