proposal: x/net/xsrftoken: should token hashing be migrated to another hash algorithm? #75932
Description
Proposal Details
SHA-1 is commented in its package as something to avoid using in applications.
https://pkg.go.dev/crypto/sha1
however, the packages that currently still use it are:
- xsrftoken
- websocket
for websocket, SHA-1 usage is explicitly required by the RFC 6455 specification, so it cannot be changed.
xsrftoken is a known issue that was marked to update in the past but has been left unresolved. @seankhliao also participated in the issue in 2025, but no action has been taken.
#19489
SHA-1 signatures are gradually becoming legacy, as new certificates (including DigiCert) are being issued with modern algorithms and old SHA-1-based certificates are being deprecated. (this is an example of SHA-1 falling out of use)
xsrf and csrf have the same purpose and are similar, but in the code xsrf differs in that it does not perform origin checks.
some considerations are:
- keep the current implementation and eventually remove xsrftoken
- in this case, users should be encouraged to migrate to csrf
- migrate to a different hash algorithm
- in this case, decide whether to fully maintain the current xsrf token behavior or apply slight modifications
personally, i would prefer to migrate xsrf to another hash algorithm because it is simple, easy to use, and keeps the source code small. however, it is unclear how beneficial this change would be overall.
in practice, tokens have a default 24-hour expiration, and after updating the package, newly issued tokens signed with a new hash algorithm using the server’s secret key should work fine. however, if the client validates tokens at generation time, problems may occur.
should SHA-1, which is not recommended for use, be allowed, or should it be kept as a backward-compatible option?
thank you for guiding me on this matter @thepudds