View Single Post
Old 28 Dec 2016, 08:32 AM   #32
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Quote:
Originally Posted by BritTim View Post
I deliberately waited quite a while before answering, rereading your points several times. I wanted to be clear in my mind that what I believe to be a reasonable position truly is.
Thanks for doing that. I've let this sit through Christmas as well, to wait until I'm back in the office and can sit down without distraction to reply.


Quote:
I see two main areas where alternative restricted logins can be of benefit:
  • 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.
  • 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.

I do not regard the above to be exotic options of benefit to only a tiny number of users. Separation of user and administrative concerns is quite common. Time limited access rights are of proven value.

I am sure implementation would raise some detailed challenges. However, I would argue the basic structure is not that complex.

The session could have a flag that indicates whether or not administrative rights are available. Web interface menus adapt accordingly, together with checks when entering an administration page that it should be allowed.
I wouldn't implement it that way. I would require that the second factor be entered again to upgrade a session to administrative mode, and that the upgrade be time limited. Certainly for anything non-reversible. I'm going to create a specific feature request for this idea and flag it for our next security review meeting (we hold them every few months), and we're due for one in January.

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?
I think this is going into the "too complex" territory, and SMS OTP is already known awful for security (not to mention deliverability, I had someone yesterday who had SMSes failing all day due to who knows what - he's in Australia and using the same provider I am and mine is fine, but his was ported between two providers in such a way that maybe their interlink died over Christmas. Who knows. There's no insight).

Overall, I'm quite happy that "enter fresh second factor to upgrade this session to administrative for 30 minutes" solves all the realistic risk cases while being very easy to understand.
brong is offline   Reply With Quote