6

我认识的一家公司正在讨论加强其所有 Web 应用程序产品的密码安全策略。

现在，他们正在通过 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 发送的数据。

4

10 回答 10

12

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

推出自己的安全解决方案可能非常危险，即使实施得当（0.000001% 的机会），也会很昂贵。

于 2009-04-03T19:32:47.200 回答
5

如果数据本身不太敏感，但密码很敏感，我建议使用HTTP 摘要身份验证（这与 HTTP 基本身份验证完全不同）。它通过直接 HTTP 非常安全，并且在服务器上实现一点也不难。没有任何东西通过网络发送可以揭示密码是什么，只是允许客户端向服务器证明他们拥有正确密码的信息。

如果您想对如何在您的应用程序中实现 HTTP 摘要身份验证有一个体面的解释，Paul James 有一篇关于它的优秀文章。

HTTP 身份验证的唯一真正问题在于浏览器本身：UI 很糟糕，但可以通过一些 Javascript 来克服。

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

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

更新：您不能通过 POST 保护数据，除非您 (a) 在客户端上使用 JavaScript 进行加密，或者 (b) 通过 SSL 进行所有操作。

您可以通过一点点魔术，将 HTTP 身份验证与表单一起使用。毕竟，我在上面链接到的那篇文章叫做“带有 HTML 表单的 HTTP Auth”。但这不会通过 POST 完成。

如果你真的需要它，请使用 POST，使用 SSL 并对数据库中的密码进行加盐。

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

于 2009-04-03T19:38:26.017 回答
3

+1 对Mehrdad 的回答。继续使用本土密码学是有风险的。

在看到本土客户端加密解决方案的漏洞之后，从这里的经验说起。大多数漏洞都是由于相同的原因 - 数据传输受到密钥加密的保护，但密钥本身以不安全的方式交换。

TLS/SSL 不仅解决了安全密钥交换问题，还解决了安全数据传输问题。

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

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

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

于 2009-04-04T15:26:00.153 回答
2

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

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

于 2009-04-03T19:39:52.860 回答
2

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

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

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

...只需使用 SSL。

于 2009-04-03T19:40:09.507 回答
2

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

时间==金钱

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

于 2009-04-03T19:54:40.250 回答
1

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

于 2009-04-03T20:12:58.617 回答
1

好吧，有一些内部讨论是关于对密码进行某种滚动我们自己的客户端加密（密码+盐等）。

我们需要解决的第一件事是传输中的数据与静态数据。从 OP 看来，最大的担忧是互联网上的用户名/密码。所以，你真的很关心传输中的数据。通过 SSL 的 HTTPS 是一种经过测试的方法（这是一个非常简单的修复方法！）。现在，如果您真的想为静态数据（在数据库中、文件服务器上等）滚动自己的数据，那是另一回事，但现有的数据加密方法将比您自己的滚动更好.

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

Roll-your-own 不会受到现有解决方案的审查。由于代码，您最终可能会在混合中添加额外的安全问题。

于 2009-04-03T20:56:48.650 回答
1

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

于 2010-08-28T18:24:51.797 回答
0

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

而且你对密码进行双重哈希......有些人可能会争辩说双重哈希会使它容易受到冲突攻击。我不得不不同意，因为到目前为止人们只能在文件上进行 md5 签名冲突，其中大量数据是 md5'ed...

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

于 2009-04-06T13:49:04.160 回答