Quote:
Originally Posted by BritTim
People who, on occasion, need to use computers whose status is uncertain can benefit from a combination of one-time passwords and a session that does not allow administrative functions. It is true that, in theory, an active one-time session can be exploited in the background to steal data or impersonate you on emails sent out by malware. It is very difficult to do this in a way that is not visible. In particular, the oft made argument that password reset requests can be made and completed within a one-time session without the user noticing strikes me as fanciful in most cases. On the other hand, stolen credentials (especially those allowing administrative rights) that can be used at leisure are extremely dangerous. Nefarious activities are very likely to go unnoticed.
|
While I agree that a limit to administrative functions makes some sense in this case, I'm not sure that a separate OTP system provides any more benefit than the new 2FA model already does.
Even then, I'm not sure limited administrative functions are much more than security theatre either. I mean, they provide some real security, but against what particular threat model? A hijacked session? Most changes a hijacker could make in administrative preferences aren't usually anything critical, and a log/notification of administrative access changes might serve just as well in this case. It would also require an attacker to have built something to mess with the FastMail UI
specifically.
Security changes still can't be reset without providing the
real password — although how that's now handled should be the subject of a separate discussion, since of course if you've entered it once, even with 2FA, an attacker theoretically has that password and can replay it into the security preferences field (in your current session). I would agree that this needs to be shored up somehow when working on "untrusted" computers.
Placing a similar restriction on making other major administrative changes, such as adding/removing domains and aliases, could be locked behind a similar additional level of authentication as well, which would make sense to me — these aren't things that users change on a regular enough basis to have a need to justify "casual" access to them without authenticating again to prove that your session hasn't been hijacked, either by malware or by somebody walking up to your PC that you've left logged in
Quote:
|
In a business context, we often wish to restrict the ability of individual users to modify rules, specify the devices on which they can access mail, and certain other actions. While we could simply lock the user out from the web interface altogether and mandate use of external mail clients, this seems an unfortunate requirement. We would like to be able to specify that the user can use the web interface to carry out activities analogous to those available in a regular IMAP client, but require administrator assistance for other actions.
|
Or in a family context. I support this particular one wholeheartedly, and I think that it's easily the most compelling argument to allow for a limit to administrative functions.
Quote:
For one-time passwords, I would suggest- A setting indicates that one-time passwords can be sent via SMS to the specified phone number. Sessions using one-time passwords would always be limited (no administrative function) sessions.
- The login screen has an option to the right of the password field "Request one-time password".
- A short time out (300 seconds, perhaps) is established for sessions initiated using one-time passwords.
Other opinions?
|
Other than isolating admin functions and providing a session timeout, I'm still a bit unclear on how you see the OTPs differing from the new 2FA system that's already in place. Granted, in the above scenario the user doesn't need to supply their "real" password, but as long as restricting administrative functions is addressed in a better way, the "real" password is largely irrelevant without the second factor (which of course is the point of 2FA).
Obviously if you're talking about administrative restrictions, there needs to be a way to differentiate the session, but that could just as easily be accomplished with an "untrusted computer" style checkbox. Remember that as long as we're talking about using 2FA, we don't get re-playable credentials anyway, so a hijacked session and intercepted password would be of no benefit provided the limited session access was properly handled by FastMail on the back-end (and again, admin functions were properly locked down in such a way that having the one-factor password wouldn't open up access to things that it shouldn't).
Anyway, some good thoughts here either way, and it's an interesting discussion. Ultimately I'm just playing devil's advocate here