Replacing hashing password scheme with something more robust

[jsjoeio]

While hashing is a major step forward, the problem with this approach is that it still allows attackers who have access to the hash to just submit it as-is and gain access to code-server - effectively not very different from storing it in plaintext.

We should definitely look into replacing this with something more robust so that password hashing isn't just a placebo.

As security expert @oxy points out, our current approach for hashing the password and storing it in a cookie is more like a placebo-effect than a real security approach.

#3422 (comment)

Related:

• fix: use sufficient computational effort for password hash #3422
• Issue warning to folks using old sha256 hashed password #3560

[oxy]

One possible route forward is to generate a token when code-server is started, and then return that token if authentication was successful - this means that you'd need to re-auth if you restart code-server, but I think its an acceptable middle ground between security and ease-of-use.

[jsjoeio]

this means that you'd need to re-auth if you restart code-server, but I think its an acceptable middle ground between security and ease-of-use

Agreed! I like the sound of that approach.

[Livven]

If I understand correctly the password hash is directly set as a cookie, instead of using some kind of session token, which is why a leak of the password hash on the server would allow attackers to authenticate with the password hash without knowing the original password, right?

In that case what you could do is to store sha256(argon2(password)) on the server and set argon2(password) as a cookie. This way, if an attacker steals sha256(argon2(password)) from the server, they would still not be able to authenticate.

Note that a simple sha256 is adequate here since argon2 already takes care of the key stretching.

As a bonus, you could even offload argon2 computation to the client as server relief, thanks to the additional sha256 on the server.

[jsjoeio]

If I understand correctly the password hash is directly set as a cookie, instead of using some kind of session token, which is why a leak of the password hash on the server would allow attackers to authenticate with the password hash without knowing the original password, right?

Exactly!

In that case what you could do is to store sha256(argon2(password)) on the server and set argon2(password) as a cookie. This way, if an attacker steals sha256(argon2(password)) from the server, they would still not be able to authenticate.

Wow, this seems very straightforward to implement (and test too). Thanks so much for the suggestion and the tips! 🙌 Really appreciate it.

[jsjoeio]

Note to self: we may actually move away from argon2. It requires native binaries and has caused a lot of problems with Termux, Raspberry Pi and other devices/environments.

[jsjoeio]

We've also talked about moving to a session token which I believe VS Code has built-in support for.

[jsjoeio]

node-rs now publishes an argon2 package. Might help here: https://github.com/napi-rs/node-rs/tree/main/packages/argon2