通过HTTP发送Web表单身份验证数据的最佳方法是什么？

Question

我所知道的一家公司正在讨论如何确保其所有网络应用产品的密码安全政策。

现在他们正在通过HTTP在POST表单中发送用户名/密码身份验证，因此，他们正在发送纯文本。

解决问题的最简单方法就是在所有应用程序中使用HTTPS进行登录，对吧？

嗯，有一些内部讨论，而不是做一些滚动我们自己的客户端密码加密（密码+盐等）。

是否有可接受的仅限HTTP的解决方案？

意见就像......好吧，每个人都有意见，所以我正在寻找可以支持你推荐的可靠安全文献。不要只是谷歌并将我发送到博客文章......我已经做到了这一点，并进一步。

我找到了OWASP的建议： http://www.owasp.org/index.php/Top_10_2007-A7#Protection

以及微软的： http://msdn.microsoft.com/en-us/library/aa302420.aspx

编辑：仅提供使用SSL的建议是不够​​的。我需要某种支持文档。我知道滚动我们自己的客户端加密是不好的。我需要能够可靠地将其出售给同事和管理层。

此外，还提到了HTTP Digest。看起来不错，但Digest仅用于HTTP身份验证，而不适用于通过POST发送的数据。

Answer 1

我强烈建议使用您自己的解决方案（在安全敏感环境中）。使用SSL。它是一种经过验证的技术，易于实施。

滚动您自己的安全解决方案可能非常危险，即使它已正确实施（0.000001％几率）， 也会非常昂贵。

Answer 2

如果数据本身不是太敏感，但密码是，我建议使用HTTP digest authentication（这与HTTP基本身份验证完全不同）。它比直接HTTP更安全，并且在服务器上实现起来并不困难。没有任何内容通过网络发送，可以揭示密码是什么，只是允许客户端向服务器证明他们有正确密码的信息。

如果您想要了解如何在应用程序中实现HTTP摘要身份验证，Paul James has an excellent article on it。

HTTP身份验证的唯一真正问题在于浏览器本身：UI很糟糕，但可能是overcome with some Javascript。

您可以通过存储A1哈希来安全地存储密码。

更新：正如其他答案所述，虽然服务器可以通过不接受基本身份验证来避免MITM攻击，但客户端仍然容易受到攻击，因为它会。

更新：除非您（a）在客户端上使用JavaScript加密，或（b）通过SSL执行所有操作，否则无法通过POST保护数据。

你可以，有点魔力，使用HTTP auth和表单。毕竟，我上面链接的文章称为“带有HTML表单的HTTP Auth”。但这不会通过POST完成。

如果确实需要它，请使用POST，使用SSL并在数据库中加密密码。

如果你想避免使用CSRF，我建议使用formkeys，虽然这个想法有很多不同的名字，但是几年前我从黑客攻击Slashcode中获取了这个名字供我自己使用，这是我遇到的地方它首先。

Answer 3

+1到Mehrdad's answer。继续使用本土密码学是有风险的。

根据经验，在看到本土客户端加密解决方案中的漏洞之后。大多数漏洞都是由于同样的原因 - 数据传输受到使用密钥加密的保护，但密钥本身以不安全的方式进行交换。

TLS / SSL解决了安全密钥交换以及安全数据传输等问题。

TLS / SSL通过使用非对称密钥加密来保护您的敏感信息，以便在建立TLS / SSL会话后交换用于来回加密信息的对称密钥。对称密钥在运行时生成，是客户端和服务器之间的共享密钥;正是这个密钥用于在会话准备好传输数据时加密所有其他流量。

服务器的公钥和私钥仅用于交换此共享密钥。破坏共享密钥的唯一已知方法是破坏服务器的私钥（以便然后可以解密密钥）。实际上，它需要服务器管理员的疏忽或恶意。

如果您使用自己的加密解决方案，则必须以安全的方式交换对称密钥。最简单的方法是使用TLS / SSL;更难的方法是实现自己的非对称密钥交换密码解决方案。

Answer 4

仅HTTP解决方案总是容易受到中间人攻击。

编辑：网络跟踪是证明HTTP不安全的简单方法。

Answer 5

客户端加密对大多数MITM攻击无能为力。攻击者可以简单地删除你的脚本。

它只能防止被动嗅探。如果这对您来说足够好，您可以使用：

• 在Javascript中实现哈希。在初始登录时很容易实现质询 - 响应，但不要忘记，对于攻击者会话cookie几乎与密码一样好（您必须限制登录到单个IP和/或使用脚本生成一次性cookie每一个请求，我认为这将是困难和脆弱的解决方案）。
• HTTP摘要式身份验证。更安全，因为它可以使用一次性哈希，相互身份验证等，但标准UI绝对令人厌恶。

...只需使用SSL。

Answer 6

您将花费更多时间和金钱来推广自己的解决方案，而不是确保它是安全的。行业标准SSL易于实施，开箱即用的安全性远远超出您自己制定解决方案的能力。

时间==钱

购买证书并花时间处理您的应用程序而不是安全登录表单。

Answer 7

好的，这是您需要的唯一答案：您的BANK仅支持通过SSL登录/验证。如果有更好的方法，他们会。

Answer 8

  

嗯，有一些内部讨论   而是做某种事   滚动我们自己的客户端加密   密码（密码+盐等）。

我们需要解决的第一件事是传输中的数据与静止时的数据。从OP看起来，最重要的是通过互联网明确用户名/密码。所以，你真的关心传输中的数据。通过SSL的HTTPS是一种经过测试的方法（这是一个非常简单的修复！）。现在，如果你真的想要为静态数据（在数据库中，在文件服务器上等）推出自己的数据，这是一个不同的野兽，但现有的数据加密方法将比自己的更好。

依靠客户端来保证安全性是不好的。期。在企业环境中，是的，您可以在某种程度上依赖于标准设置。但是，最终，用户是愚蠢的，你可能会遇到禁用javascript或任何基于客户端的解决方案的人，所以他们最终会以纯文本形式发送用户名/密码（即使你的服务器不知道如何处理它）因为它不是预期的格式。

自己动手不会受到现有解决方案的严格审查。由于代码原因，您最终可能会在混合中添加其他安全问题。

Answer 9

我们刚推出了一个网络/移动应用来完成这些工作。它使用HTTPS和数据库存储的散列/ AES加密方法为登录创建随机URL。这是一个简单的JSON API，可以在没有我们的UI的情况下使用它，继承我们的文章，看一看.. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it

Answer 10

你提到自己加密加盐...我建议使用javascript md5（雅虎在非ssl页面上也使用它，或者他声称这样做）......

你加密哈希密码...有些人可能认为双重哈希它会使它容易发生碰撞攻击。我不得不反对，因为人们已经能够直到现在才对文件进行md5签名冲突，其中大量数据是md5'ed ...

如果它是一个大型企业网站（并且有理由闯入），没有理由不使用SSL。