You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Replacing hashing password scheme with something more robust #3576
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.
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.
Reacted by Joe Previte, Aditya Kumar and Anthony Thyssen
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.
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.
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.
Activity
oxy commentedon Jun 9, 2021
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 commentedon Jun 9, 2021
Agreed! I like the sound of that approach.
Livven commentedon Jun 11, 2021
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 setargon2(password)as a cookie. This way, if an attacker stealssha256(argon2(password))from the server, they would still not be able to authenticate.Note that a simple
sha256is adequate here sinceargon2already takes care of the key stretching.As a bonus, you could even offload
argon2computation to the client as server relief, thanks to the additionalsha256on the server.jsjoeio commentedon Jun 11, 2021
Exactly!
Wow, this seems very straightforward to implement (and test too). Thanks so much for the suggestion and the tips! 🙌 Really appreciate it.
jsjoeio commentedon Jan 3, 2022
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 commentedon Jan 3, 2022
We've also talked about moving to a session token which I believe VS Code has built-in support for.
jsjoeio commentedon Jan 3, 2022
node-rs now publishes an argon2 package. Might help here: https://github.com/napi-rs/node-rs/tree/main/packages/argon2
code-asher commentedon Jul 13, 2024
Merging with #3546