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]

Replacing the "/login" sub-path of code server, and using our authentaction system, and setting the session-cookie, just seemed
to be simpeist. Then have no need to handle sessions ourselves, as we previously did.

There will be a LOT (500+) users, though we expect only a maximum of around 60 at any one time.

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. It needed a redis database to hold information about the user, even though once the user was logged into code-server they no longer needed to use the authentation system. 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 development environment,
If they don't have a session cookie, code-server jumps to "/login" which is overlaid by our auth system. They are authenticated (often already done), and the 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).

Most of the time code-server accepts the hash we create from the password. I have confirmed the session-cookie hash I generate verifies against the password stored in the code-server.

But when code-server doesn't accept the session cookie as valid, it jumps back to the '/login' sub-path, their auth is transparently and quickly confirmed, and a new hash of their password is set as the cookie, before it again ends them back to code-server top-level.

What is happening is that when the cookie is not accepted. No re-hashing of the password gathered from the code-server config, ever seemed to be accepted as valid! This results in a endless browser re-direction loop (until browser put a halt to it).

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, and I have again manually confirmed that the refected cookie hash, does verifiy against the config password.

Then I thought it was the argon2 params being checked, and found to not be good enough as I had been forced to use less secure parameters (thus the original request). That has now been resolved. Example params $argon2id$v=19$m=20480,t=3,p=2$

Now I got the feeling that the code-server is internally using a slightly 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, It never accepted at all,
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 every-time code-server is restarted, so a new password is generated on startup.
It should not matter what that password is, it is collected hashed and used to set the session cookie. It just sometimes works, and sometimes doesn't.

[antofthy]

Okay... Found the faults. I had HttpOnly set on the cookie.
And I was not URL escaping the hash when setting the cookie...

I don't know why it was sometimes working, while other times it didn't.
Still. I believe I have it all working now, and will be doing more tests Monday to unsure that is the case.

On monday I will post here some of the password/cookie testing 'curl' commands I used to debug this, but right now -- weekend! Yeah!