这听起来很像一个“管理员”帐户，否则它通常可以无限制地访问它是管理员的东西。

管理员帐户的安全含义以及最佳实践都非常容易理解。我不会详细介绍所有细节，但您的实现在一个关键特性上违反了最佳实践：可追溯性。

您希望能够知道谁做了什么，尤其是在涉及管理员时。如果管理员可以使用他的密码登录我的帐户，那么审计员在事后就无法确定我所做的与管理员所做的。

但是，如果管理员使用他的超级安全密码登录到他的 OWN 帐户，那么通过他通过他自己的帐户拥有的访问权限执行一些我也可以完成的操作 - 那么现在我们可以有一个日志来告诉谁做了什么。当粪便击中风扇时，这是非常关键的。当其中一个管理员帐户受到威胁时（尽管您尽了最大努力，它会受到威胁）更是如此。

此外，假设业务增长并且您需要 2 个管理员。他们是否分享了超棒的密码？不不不。他们都有自己的管理员帐户，具有单独的跟踪和日志记录等等。现在你可以知道哪个管理员做了什么。而且，最重要的是，当您解雇一名偷甜甜圈的管理员时，您可以关闭其中一个帐户。

到目前为止给出的答案中有很多重要的信息，原始海报应该阅读并牢记。但是，我认为大多数答案都没有抓住问题的精神，因为它与“就好像他们是用户一样”为了支持目的而遍历他们公司的网站有关。问题的核心似乎是此活动发生在网站的前端，而不是服务器的控制台。

我知道一家公司在其 Web 应用程序中有同样的需求，并且已经以一种我认为是原始发布者正在寻找的解决方案的方式解决了它。

他们在他们的 web 应用程序中创建了一个“伪装”系统，允许特殊组中的员工进入一组页面，这些页面可以查找系统中的任何用户，并选择该用户作为浏览系统的凭据。它跟踪选择伪装成的用户和实际员工用户作为两个独立且同时的实体，这两个实体都被记录在任何时候，并且针对每个操作。

从应用程序的角度来看，它是“把我当作这个用户，但请记住我实际上是这个其他用户”。类似于 sudo 的 webapp 版本，但内置于前端。

这种方法：

1. 消除了审计跟踪的噩梦，因为两个用户帐户都始终被跟踪。
2. 为员工提供页面的准确“用户视图”。
3. 维护员工的个人凭据，以便没有共享或“主”密码。
4. 维护用户的安全，员工永远无法使用其密码。
5. 将解决方案保留在应用程序层，在网站上，这样任何人都可以在没有系统级访问权限或知识的情况下执行此操作。
6. 员工还可以随时“取消伪装”并根据自己的帐户或其他用户帐户检查页面内容，这对于确定错误是全局的还是特定于用户的非常有帮助。

是的，这是一个错误。如果攻击者设法获得了这个密码，不管你认为它有多安全，会发生什么？他将能够以一种最有可能难以与正常活动区分开来的方式篡改用户帐户信息。

如果您控制该网站，则您已经有许多不同的方法可供您选择支持。可以编写适当的管理工具来读取和修改必要的信息。拥有“主”密码没有多大意义。

这个“上帝”密码相当于root/Administrator访问权限：可以做任何事情。问题是双重的：

1. 拥有某种“无所不能”的访问权限是个好主意吗？在实践中，它比“好”更“不可避免”，但是，是的，这是正常的事情。但是，请确保有适当的使用程序：您不希望管理员在咖啡店的共享机器上进行管理；你想知道“谁不知道”。从这个意义上说，当有两个或更多个人被授予管理员权限时，最好让他们“充当自己”作为管理员组的成员（在 Unix 世界中，使用sudo以便记录命令）。

2. 让管理员通过普通用户 API行使权限是个好主意吗？这个值得商榷。允许“上帝密码”意味着在整个应用程序中安装“上帝例外”，这可能会被滥用。它增加了您站点中身份验证+授权系统的复杂性，而复杂性是您在安全方面要避免的一件事。错误在复杂性中茁壮成长。“上帝密码”在开发过程中可能很方便，但一般来说，它往往会增加破坏性安全漏洞的可能性，因此请谨慎使用。

当然，上下文就是一切，上面的答案通常只适用。尽管如此，还是要警惕行政后门，尤其是那些不能很好地记录行政请求来源的后门。