Login/2FA trust device

[stdedos]

What's the problem this feature will solve?
Short (?) login sessions and not trusted devices make non Yubikey authentications lengthy (Ofc, if your Yubikey is e.g. in your keychain, you also need to fetch it every time).

Describe the solution you'd like
Introduce the notion of "Keep me signed in" or "Trust this device and don't ask 2FA for it again".

Additional context
A lot of major services do it, I cannot see the reason (besides time and effort) not to be included.

[callmecampos]

Some initial questions on this one:

1. How long should devices stay signed in once they're trusted (e.g. 1 week, 30 days, 1 year)?
2. How should we go about device fingerprinting?

[stdedos]

If you are asking me:

1. Permanently. e.g. Gmail, Github has been doing that forever, I guess they have already balanced/figured out how to do that safely. Functionality should be similar to "Keep me logged in", and I guess that problem is somehow solved already. If not, a fair balancing would be 2-4 weeks.
2. I am not sure if that is wise, and a lot of people (including me) attempt to mask their fingerprint. Not being an expert, some https://en.wikipedia.org/wiki/Zero-knowledge_proof with a secret key stored in user's account & browser, POSTed while logging in should be enough?
   If there is an answer to that somewhere online, or you implement something, I would be interested to know the implementation picked.

[callmecampos]

To (1), in talking with @di, 30 days seems to be a reasonable time frame for now. Implementing this should just require storing the relevant session auth cookie information in a Postgres database as opposed to Redis (where it's currently stored for 12 hour expiration lifetime sessions, see warehouse/sessions.py), since that will guarantee that the session information can be stored for those 30 days (Redis is an in-memory db, so doesn't guarantee that).

For (2), the main concern is whether you could take a session auth cookie from one device, put it on another, and have it authenticate on the other device. If this isn't really a concern, or session cookies as they're implemented in warehouse/sessions.py already somehow handle this, then it should be fine to leave as is.

Other risks are users who are not the intended user having access to a browser with those session cookies on them (e.g. cookie dropped on a public library computer, intended user leaves and forgets to explicitly log out, another user sits down and is already logged in). There's not much we can do to get around that outside of warning the user when clicking "Remember me" that they should be on a private computer.

Finally, and this should probably be filed as a separate issue, is that we should always require to re-authenticate any time "important" or "destructive" actions are done if the user hasn't authenticated recently (say in the last 15 minutes). This includes:

1. Changing passwords
2. Changing email address or other contact information
3. Deleting distributions
4. Adding/removing maintainers
5. Generating API tokens

Most of these are done in the accounts page, but will require some work to make sure that all the right endpoints are protected by an authentication page.

[stdedos]

To (1), in talking with @di, 30 days seems to be a reasonable time frame for now. Implementing this should just require storing the relevant session auth cookie information in a Postgres database as opposed to Redis (where it's currently stored for 12 hour expiration lifetime sessions, see warehouse/sessions.py), since that will guarantee that the session information can be stored for those 30 days (Redis is an in-memory db, so doesn't guarantee that).

While obviously not-as-spec'ed, I would look the other way for a prototype/performance reasons, if you'd stick with Redis (unless it goes into maintenance too much).

For (2), the main concern is whether you could take a session auth cookie from one device, put it on another, and have it authenticate on the other device. If this isn't really a concern, or session cookies as they're implemented in warehouse/sessions.py already somehow handle this, then it should be fine to leave as is.

Other risks are users who are not the intended user having access to a browser with those session cookies on them (e.g. cookie dropped on a public library computer, intended user leaves and forgets to explicitly log out, another user sits down and is already logged in). There's not much we can do to get around that outside of warning the user when clicking "Remember me" that they should be on a private computer.

I am about to do this exact thing, now that I am migrating from my old, to my new system. It saves a lot of trouble to re-trust and disavow devices.

You could counteract this by minimizing valid login time to ~4h (or whatever your site statistics say it is safe to change this value to).

[di]

@ewdurbin you said in chat:

Think we’d need some device fingerprinting and DB sessions to make that work?

Can you go into more detail here?

[di]

Just realized this is a duplicate of #5867, so closing in favor of that issue.

[stdedos]

Whatever makes the issue move forward 😄