Change Details

**The Problem:** Administrators of any online collaboration platform, including Phabricator, typically discover !!a need for all-access or near-all-access controls!! in order to properly maintain the community. Many Phabricator users have expressed a desire for these kinds of features. However, the equally weighty problem that @epriestley and @chad have brought up is that, !!if compromised, an all-access admin account is now an open door to crackers!!. Simply put, the benefits of an all-access accounts are far outweighed by the security risk. **The Current Solution:** To offset the inconvenience, anyone with access to the server controls (a far more secure interface) can manage Phabricator user accounts and perform some override actions (such as freeing some object policies). This does not provide the full set of obvious or necessary controls, however, and many actions (especially edits) require manual login as another user. To do this, either the admins must maintain a list of issued passwords (security risk), or force users to change passwords after they manually overriding the current password via server controls so they can log in. Neither of these solutions are ideal by any measure. **The Proposed Solution:** Over lunch, the thought occurred to me that we can find a safe compromise between both views, by creating a __fourth kind of user account__, which I'll call a `hammer` for the moment (borrowing from my IRC days). A `hammer` account would have the following features. - Can only be created via the server interface. - Automatically generated username (`hammer`, followed by 16+ random characters) and very strong password (64+ characters, including letters, numbers, and symbols) - copy and paste from the server terminal is easy, but it would be mathematically impossible to crack it within the account's lifespan. - Forced maximum lifespan of (two?) hours - plenty of time to perform any necessary action. After the lifespan ends, or after the account is logged out of (whichever happens first), the hammer account is automatically destroyed. - All `hammer` actions are attributed to a "System Administrator" bot account, which was automatically created by Phabricator, which has no direct login, and cannot be modified or deleted. - A `hammer` account has all-access control to everything. - Optional `localhost access only` setting could prevent `hammer` logins from any IP besides `localhost`, adding a layer of steel to the security of the feature. **Other Benefits:** Another benefit of having a `hammer` account feature is that it would further discourage less-experienced admins from doing unsafe things, like deleting or blowing policy wide open on something the admin wants to edit or remove. The fact they can "hammer-up" and use Phabricator's usual web interface will encourage them to use the typical edit and hide features. Also, since actions are taking place via the normal Phabricator interface, and are being attributed to `System Administrator`, admin actions are completely transparent and, in many cases, reversible by the user in question.

**The Problem:** Administrators of any online collaboration platform, including Phabricator, typically discover !!a need for all-access or near-all-access controls!! in order to properly maintain the community. Many Phabricator users have expressed a desire for these kinds of features. However, the equally weighty problem that @epriestley and @chad have brought up is that, !!if compromised, an all-access admin account is now an open door to crackers!!. Simply put, the benefits of an all-access accounts are far outweighed by the security risk. **The Current Solution:** To offset the inconvenience, anyone with access to the server controls (a far more secure interface) can manage Phabricator user accounts and perform some override actions (such as freeing some object policies). This does not provide the full set of obvious or necessary controls, however, and many actions (especially edits) require manual login as another user. To do this, either the admins must maintain a list of issued passwords (security risk), or force users to change passwords after they manually overriding the current password via server controls so they can log in. Neither of these solutions are ideal by any measure. **The Proposed Solution:** Over lunch, the thought occurred to me that we can find a safe compromise between both views, by creating a __fourth kind of user account__, which I'll call a `hammer` for the moment (borrowing from my IRC days). A `hammer` account would have the following features. - Can only be created via the server interface. - Automatically generated username (`hammer`, followed by 16+ random characters) and very strong password (64+ characters, including letters, numbers, and symbols) - copy and paste from the server terminal is easy, but it would be mathematically impossible to crack it within the account's lifespan. - Forced maximum lifespan of (two?) hours - plenty of time to perform any necessary action. After the lifespan ends, or after the account is logged out of (whichever happens first), the hammer account is automatically destroyed. - All `hammer` actions are attributed to a "System Administrator" bot account, which was automatically created by Phabricator, has no direct login, and cannot be modified or deleted. - A `hammer` account has all-access control to everything, regardless of space, scope, view, or edit privileges. - Optional `localhost access only` setting could prevent `hammer` logins from any IP besides `localhost`, adding a layer of steel to the security of the feature. **Other Benefits:** Another benefit of having a `hammer` account feature is that it would further discourage less-experienced admins from doing unsafe things, like deleting or blowing policy wide open on something the admin wants to edit or remove. The fact they can "hammer-up" and use Phabricator's usual web interface will encourage them to use the typical edit and hide features. Also, since actions are taking place via the normal Phabricator interface, and are being attributed to `System Administrator`, admin actions are completely transparent and, in many cases, reversible by the user in question.

**The Problem:** Administrators of any online collaboration platform, including Phabricator, typically discover !!a need for all-access or near-all-access controls!! in order to properly maintain the community. Many Phabricator users have expressed a desire for these kinds of features. However, the equally weighty problem that @epriestley and @chad have brought up is that, !!if compromised, an all-access admin account is now an open door to crackers!!. Simply put, the benefits of an all-access accounts are far outweighed by the security risk. **The Current Solution:** To offset the inconvenience, anyone with access to the server controls (a far more secure interface) can manage Phabricator user accounts and perform some override actions (such as freeing some object policies). This does not provide the full set of obvious or necessary controls, however, and many actions (especially edits) require manual login as another user. To do this, either the admins must maintain a list of issued passwords (security risk), or force users to change passwords after they manually overriding the current password via server controls so they can log in. Neither of these solutions are ideal by any measure. **The Proposed Solution:** Over lunch, the thought occurred to me that we can find a safe compromise between both views, by creating a __fourth kind of user account__, which I'll call a `hammer` for the moment (borrowing from my IRC days). A `hammer` account would have the following features. - Can only be created via the server interface. - Automatically generated username (`hammer`, followed by 16+ random characters) and very strong password (64+ characters, including letters, numbers, and symbols) - copy and paste from the server terminal is easy, but it would be mathematically impossible to crack it within the account's lifespan. - Forced maximum lifespan of (two?) hours - plenty of time to perform any necessary action. After the lifespan ends, or after the account is logged out of (whichever happens first), the hammer account is automatically destroyed. - All `hammer` actions are attributed to a "System Administrator" bot account, which was automatically created by Phabricator, which has no direct login, and cannot be modified or deleted. - A `hammer` account has all-access control to everything, regardless of space, scope, view, or edit privileges. - Optional `localhost access only` setting could prevent `hammer` logins from any IP besides `localhost`, adding a layer of steel to the security of the feature. **Other Benefits:** Another benefit of having a `hammer` account feature is that it would further discourage less-experienced admins from doing unsafe things, like deleting or blowing policy wide open on something the admin wants to edit or remove. The fact they can "hammer-up" and use Phabricator's usual web interface will encourage them to use the typical edit and hide features. Also, since actions are taking place via the normal Phabricator interface, and are being attributed to `System Administrator`, admin actions are completely transparent and, in many cases, reversible by the user in question.