Simplify password authentication #43
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fusion's existing session handling logic is a bit incorrect but it still works due to workarounds. sessions.NewCookieStore is supposed to receive a secure, random value: https://pkg.go.dev/github.com/gorilla/sessions#section-readme fusion currently passes it a fixed string baked into source. The result is that an attacker can forge a valid session token (they know the secret key) and send it to a fusion server, and the server would accept it. The reason this isn't a problem right now is that fusion works around this by storing an additional copy of the password in the session and then checking the password on each authenticated request. The current implementation works, but I think it's a bit more dangerous and complicated than what's ideal. Ideally, an attacker shouldn't be able to forge a session token at all. This change makes it so that the session cookie store derives session cookies using the server password as the secure secret. That way, an attacker can't forge session tokens unless they know the server password, but if they know the server password, it's game over anyway. Because we can trust the session store to reject requests with invalid session tokens, we don't need to store additional copies of the server password. We can trust that if the request has a valid session token, it's a token that the server created.
|
Thanks! |
mtlynch
added a commit
to mtlynch/fusion
that referenced
this pull request
Jan 19, 2025
Resolves 0x2E#53 This fixes a bug I accidentally introduced by misunderstanding the echo session package. I thought that calling session.Get would return an error if no session existed for the session token valule. It seems that instead, if a session doesn't exist, session.Get creates one on-demand. To fix this, we have to check the IsNew field of the session to see if calling session.Get created this session on-demand or if this was a session that was previously created in the Create function. I introduced this bug in 0x2E#43.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fusion's existing session handling logic is a bit incorrect but it still works due to workarounds.
sessions.NewCookieStore is supposed to receive a secure, random value:
https://pkg.go.dev/github.com/gorilla/sessions#section-readme
fusion currently passes it a fixed string baked into source. The result is that an attacker can forge a valid session token (they know the secret key) and send it to a fusion server, and the server would accept it.
The reason this isn't a problem right now is that fusion works around this by storing an additional copy of the password in the session and then checking the password on each authenticated request.
The current implementation works, but I think it's a bit more dangerous and complicated than what's ideal. Ideally, an attacker shouldn't be able to forge a session token at all.
This change makes it so that the session cookie store derives session cookies using the server password as the secure secret. That way, an attacker can't forge session tokens unless they know the server password, but if they know the server password, it's game over anyway.
Because we can trust the session store to reject requests with invalid session tokens, we don't need to store additional copies of the server password. We can trust that if the request has a valid session token, it's a token that the server created.