Cookie expiration time is set too high (90 days)

[Shnatsel]

Describe the bug

Right now the crates.io session cookie is set to be cleared by the browser in 90 days, unless refreshed.

Such a long cookie lifetime makes sense for certain other websites (e.g. Google, Github) that assume constant interaction from authenticated users. However, crates.io uses the cookie only for highly sensitive administrative tasks such as generating access tokens for Cargo or adding new publishers.

On crates.io the most common flow is "log in, perform a sensitive action, never use anything requiring authentication for weeks". There is no frequent action requiring authentication, such as commenting on issues. As such, there is no reason to keep the cookie around for that long.

To Reproduce
Steps to reproduce the behavior:

1. Go to crates.io in the browser
2. Log in with Github
3. Open Developer Console in the browser and inspect the cookies
4. Observe the cookie expiring 90 days in the future

Expected behavior
The expiration date set to 1 day or even 1 hour, to reflect the sensitivity of the cookie as well as how rarely it it is actually used.

Desktop (please complete the following information):

• OS: Any (tested on Linux)
• Browser: Firefox
• Version: 94

Additional context

Cookie theft is a common target for malware. In fact, the malware distributed as part of the recent NPM compromise was stealing cookies. It is important not to allow a single compromised package to steal credentials for other crates.io accounts.

See also: #2630

[bjorn3]

The cookie is also used to eg show you the list of crates you are watching (and the latest updates for these crates), which crates you published. Maybe the cookie could allow read/write access the first so much time and only allow read-only access (and maybe adding new crates to follow) after that until it expires? Kind of like github's "sudo mode" for security sensitive operations.

[Shnatsel]

Ah, I did not realize that because I have never used those features. Yes, having a separate cookie for write operations sound good. The only downside is that it imposes greater implementation complexity, but I suppose that can't be helped.