Quote:
Originally Posted by brong
I'd just like to look back at this little bit some more.
- restricted mode didn't make any difference to being able to view emails. Somebody extracting everything could still exfiltrate all your email
- restricted mode didn't stop you sending email, a stolen session could still be used for spam or fraud
- restricted mode still allowed you to move messages between folders, just not permanent delete
Permanent delete isn't really permanent anyway, it's just setting a \Expunged system flag, then cyr_expire cleans up the email a week later. We already offer a self-serve restore from backup, which gets you back the email in the folder it was in, rather than wherever it was moved to.
What we could do (and it's on the roadmap as a wishlist item, because it's a ton of work) is something nice where you can see "in session X you deleted 5000 messages at 5:25am from <ipaddress>[countrycode]" with a button to restore just that set of messages along with an extra folder/label which allows you to quickly view them all...
But anyway, you can get back email if someone steals your session and wipes out a ton of messages. You were never more safe from them reading all your email or moving it all around or sending stuff on your behalf by having restricted mode. It was a crappy concept that I wrote when I wasn't thinking carefully of all the implications.
Bron. |
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.
Firstly, I am not claiming either that a restricted mode is a panacea, or that the restricted mode that existed in the past was the ideal approach.
It is a fact that security features involve real effort to implement properly, and no one benefits from security theater that confers no real protection. However, it is in both the users' and in Fastmail's interest to have controls available that limit the opportunity for abuse.
I think the points you raise on the limitations of restricted sessions miss the point. 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.
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?