Holger Just wrote:
I find the concept of an opaque timespan for a grace period rather unfortunate. For an admin, it is not clear when the grace period starts: When a user logs in next? When the setting is updated? Which setting? How can I know when it's updated?
On the settings screen it's also not clear when exactly the required status will finally be enforced.
As such, I'd rather propose to ask the admin to enter a fixed timestamp when the setting will be enforced. That would make things much clearer and also would allow to shorten or extend this as required.
That was my initial solution, but I changed my mind thinking that this grace period can be used also for new users (in a future iteration). Also, I had in plan to display in the admin when the grace period expires, as I did for users in the enable 2FA page after login. Anyway, after your feedback, I think it's better to keep things simple and replace the grace period with a specific datetime.
For that, we would need:
- A UI for entering a date and time (not sure we have that somewhere yet?)
- Some server-side validation of the provided data format as we likely need to store an ISO8601 string in the DB
Apart from that, I think the 2FA activation check is only done on user login. A grace period of just a couple of hours thus might not result in a lot of users seeing the skip-option at all as existing sessions are not affected by the setting right now (correct me if I'm wrong here). A more common grace period would thus probably be a week or more.
You're right, existing sessions are not affected, the only differences compared with the "required" method are:
- the redirect to enable 2FA page after user login
- the option to leave the page
- the notification regarding 2FA
- the grace period and when it ends.
Maybe it would also be helpful to forcefully kill existing sessions of users who have not enabled 2FA after the grace period has ended? Unfortunately, I'm not sure how we could do this in plain Redmine without either checking on every request or having a persisted job queue where we could schedule stuff in the future.
Interesting option and it could be a good improvement from a security point of view because it covers also the cases with long session lifetime. Do you think it worths the effort?
Regarding the technical solution, I wouldn't check at any request, I prefer the queue option with a rake task that can be manually ran in case the queue is lost until the grace period ends (AsyncAdapter and a restart).