Security 用户名和密码存储在隐藏表单字段中的情况如何？

假设你有一个webapp，它在隐藏的表单字段中传递用户名和密码

我知道这是个很糟糕的主意，但我想列举一下为什么。。。有什么想法吗

更新-这是一个假设问题

---

我找不到一个仅仅列举原因的资源-我知道很多原因为什么这是一个坏主意，我想看看是否还有其他原因我没有想到，并创建我正在寻找的资源。谢谢

访问当前页面的任何人（可能不一定是登录到您的应用程序的同一个人）都可以很容易地查看html源代码并获取用户名和密码

---

如果我登录我的gmail，离开我的办公桌，你进来，你可以看到我所有的电子邮件信息。但是不管怎样，你都看不到我的gmail密码。但是，如果gmail以隐藏字段格式传递密码，那么你可以看到我的gmail密码。

窃听，特别是如果传输层未加密，除非你的所有页面都通过https提供，否则这是不好的，因为用户名和密码在网络上以明文形式不断发送，并且可以嗅探。 即使所有页面都通过https提供，这也很糟糕，因为如果用户忘记关闭浏览器，任何有权访问计算机的人都可以查看源代码并读取密码。

---

它给用户一种错误的安全感，我建议您尽可能地更改它。

好吧，危险因您所说的“用户名和密码”而有所不同

如果您指的是要验证的用户名和密码，我邀请您在web浏览器中选择View->Source。这根本不安全

---

如果您的意思是用户登录的用户名和密码在被发送之前被放置在一个隐藏字段中，那么它与您的标准文本和密码字段之间绝对没有区别。这里唯一的安全风险是在没有TLS/SSL连接加密的情况下以明文形式发送密码，从而允许数据包嗅探查看凭据。

这是一个糟糕主意的原因有很多：

1） 正如所指出的，如果您查看源代码、检查元素或任何类似的内容，那么用户名/密码很容易被发现

2） 除非您的传输层被加密，否则它们将很容易被拦截

3） 如果浏览器缓存您的html页面，则带有用户名/密码的文件现在存储在此人的计算机上

4） 如果该用户保存页面以提供给其他人，则其用户名/密码将与该页面一起使用

5） POST方法意外更改为GET，现在密码和用户名存储在服务器访问日志中

等等等等

在我看来，没有真正的理由这样做，特别是当您可以在服务器上使用会话cookie，或者其他一些不向客户端公开私有信息的方法时

编辑：想想看，我以前做过一次。我把一个密码放在一个隐藏的字段中，但是在这样做之前，我用一个只有服务器知道的密钥对它进行了加密，然后打印出来，当我把密码发回服务器时，我对它进行了解密。因此，客户端永远不会使用明文密码

---

编辑2：应该指出，根据霍布斯的观点，上一次编辑中描述的方法没有用于直接验证某人。

我不认为以明文形式存储用户名有那么糟糕，在某些情况下，这样做可能是有益的

然而，存储密码则是另一回事。这将是非常容易的人嗅探您的数据包通过网络（有许多点，在其旅程中，这可能会发生）和登录使用您的凭据

---

我遵循的一条黄金法则是永远不要在任何地方存储明文密码。

我认为这里最大的风险是任何XSS漏洞现在都允许密码窃取。XSS比看起来更糟糕。XSS漏洞确实没有任何借口，但人们做出的决定使其变得不可避免

第二大风险可能是缓存。这些密码最终会出现在磁盘上，任何恶意代码都可以在文件中找到它们。话虽如此，大多数密码都可以通过交换和休眠的方式保存在磁盘上，这是一个概率问题。

• 该页面可以缓存在用户的浏览器中
• 该页可以缓存在代理服务器中
• 最糟糕的是，该页面可能会被搜索引擎缓存

---

在任何情况下，包含用户名和密码的内容都可能被提供给不应该看到它的人。

通常，当我需要官方资源来列出可能的攻击或弱点时，我会求助于：

常见弱点枚举

常见攻击模式枚举与分类

软件安全错误分类

令人惊讶的是，将用户名/密码存储在一个隐藏的表单字段中是一个非常严重的错误，它在CWE中遇到了大约20个问题

为了让您开始：

---

传输层加密了吗？你能解释一下为什么需要传递它们吗？@kigurai-我不知道-这是一个假设问题@Si-再一次，假设-传输层上的什么安全措施可以减轻什么风险？我想你已经知道了，因为这是客户端的用户名和密码。但密码输入也是一样的（假设没有从https切换到http）。Re：在你的编辑中，你仍然不应该盲目地认为这是安全的。如果服务器将使用其中一个加密密码进行身份验证，那么无论您是否拥有明文密码，您都拥有所需的一切！对虽然我不是100%s