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 use code-server auth.