[Security] Invalidate auth cookie after password change

[TimLovellSmith]

From our bug bash -
Repro:
• Open edit package page in one browser
• In another browser, change the password of the same account
• Submit the changes from the first browser.
• Expected:
• It should reject the changes
• Actual:
• The changes applied.

[TimLovellSmith]

I have thought about this one and I don't really like the idea of verify every authorization cookie check stateful against SQL or whatever. The nice thing about cookies is they are supposed to help keep your app stateless. There are some compromises possible, like force stateful validation for certain actions, like account management and package management...

[analogrelay]

It's not that scary perf-wise if you instead say that every write operation performs a stateful SQL authorization cookie check, but that read operations just trust the signed cookie. Though that is a heavier work item.

[analogrelay]

Let me take a quick look and see if we can do it without checking SQL all the time.

[analogrelay]

I'll roll this in to some credential work I'm doing:

1. Persistent cookie based on a token derived from the password (hash, etc.)
2. Temporary session cookie which can be automatically refreshed from the persistent cookie and is NOT password-dependent.

[skofman1]

We deprecated password auth.