Security 如何支持使用哈希或加密密码的web应用程序？

在企业环境中支持新的web应用程序时，通常需要以特定用户的身份登录，以便诊断他们遇到的实际问题或感知到的问题。这里有两个相反的问题：

最佳做法是使用哈希密码或加密密码，而不是明文密码。有时，中间有第三方SSO（单点登录）。无法检索用户的密码。除非用户提供（不鼓励），否则无法作为该用户登录

许多web应用程序都具有个性化和复杂授权。不同的用户具有不同权限的不同角色（管理员、经理、用户）。有时用户只能看到他们的数据——他们的客户或任务。一些用户具有只读访问权限，而其他用户可以编辑。因此，每个用户对web应用的看法都是独一无二的

假设在企业环境中，去用户的办公桌或直接连接到他们的机器是不可行的

你如何处理这种情况

---

编辑：我想重申，在一家大型金融机构或典型的财富500强公司中，在全国和世界各地拥有数十万名员工，仅仅某个it部门的开发人员不可能直接访问用户的机器。其中一些是客户使用的面向公众的web应用程序（如网上银行和股票交易）。而且，其中许多是依赖于Active Directory或SSO的intranet应用程序，这意味着许多应用程序的用户凭据是相同的。谢谢大家的建议,；有些可能在其他类型的环境中非常有用。

管理员应该能够更改用户的密码。将用户的密码更改为您知道的密码。然后，您可以作为该用户登录

---

调试完成后，告诉用户重置其密码。

通常通过某种可用于查看其桌面的远程控制软件。如果它们位于Windows终端服务器上，则可以使用内置的管理工具。否则，我会在内部网络上使用VNC之类的东西，或者使用LogMeIn（）之类的外部服务

您是否有一个测试环境，其中有一个定期拷贝到的实时数据片段（显然经过消毒以满足任何安全或数据保护问题）。如果允许的话，可以使用与有问题的用户相似的设置来进行故障排除，或者实际上是用户本身

如其他答案中所述，请使用远程桌面客户端，但这对您来说可能不太实际。如果你在域内拥有这些权限，我听说过错误处理，甚至在做Screenscrap时，也会将其包含在日志中！但这听起来有点奇怪

您是否可以使用管理工具将用户克隆到演示帐户中

---

对于我们的web应用程序，由于缺少更好的术语，我们使用的过程被定义为“劫持”用户帐户

基本上，管理员只需点击一个简单的按钮就可以“劫持”用户的帐户。在代码中，您只需使用唯一标识符（用户id在不太安全的环境中工作），然后在会话中建立必要的凭据，以便它们可以在该用户的配置文件中工作。对于更安全的环境，您可以为每个用户使用唯一的哈希

---

为了确保此劫持方法是安全的，它总是首先验证请求是否由具有适当权限的经过身份验证的管理员发出。因此，有必要劫持管理员的会话或捕获其身份验证凭据，以便有人利用应用程序中的劫持功能

我有4个想法。在我打字的时候，其中3个已经被推荐了（所以我给了他们更高的票数）

想法3的变体-模仿：

要使其与普通登录“尽可能相同”，只需最少的代码更改，您可以通过提供管理员凭据和备用用户名（例如，以Admin:user、adminpassword登录）来添加在登录时直接模拟的功能。系统会将此完全视为使用userpassword以用户身份登录

---

想法4：你能进入密码库吗？如果是这样，则暂时用已知密码的哈希替换用户的哈希。（密码通常在线存储在数据库中。SQL查询工具可以进行交换）

这些想法中有许多会给用户带来不便，要么迫使他们更改密码，要么占用他们的桌面进行调试会话

Markc的想法是最好的：增强身份验证逻辑，允许超级用户以特定用户身份登录，方法不是提供用户的凭据，而是提供用户名及其超级用户凭据

我以前也这样做过（伪python）：

换句话说，如果用户名和密码没有进行身份验证，如果密码有冒号，那么它实际上是由冒号连接的管理员用户名和管理员密码，因此，如果它们是正确的管理员用户名和密码，请作为用户名登录

---

这意味着您可以作为用户登录，而不知道他们的秘密，也不会给他们带来不便。

我们在web应用程序中使用的解决方案是让authN/authZ将所需用户作为有效用户返回。我们通过使用管理员功能来设置伪装，然后当我们请求当前登录的用户（当前用户）时，我们处理伪装：

  def current_user_with_effective_user
    if masked?
      current_user_without_effective_user.masquerade_as
    else
      current_user_without_effective_user
    end
  end
  alias_method_chain, :current_user, :effective_user

---

这是不幸的：为什么用户会因为调试而感到不便呢。如果可以“克隆”用户帐户并使用它，最终用户可能不会感到不便。这可能可行，也可能不可行。此外，如果您可以使用“debuguser”帐户查看问题，这可能也是更好的选择，但它可能不会重现

  def current_user_with_effective_user
    if masked?
      current_user_without_effective_user.masquerade_as
    else
      current_user_without_effective_user
    end
  end
  alias_method_chain, :current_user, :effective_user