有没有可行的“经典”cookie身份验证替代方案？

Question

有没有办法（除了HTTP认证，我收集的内容在互联网上本身就不安全？）对于“现实生活”的网站来处理登录和身份验证而不是传统方式，使用会话cookie？

Answer 1

HTTP digest authentication（与HTTP基本身份验证完全不同）在直接HTTP上非常安全，并且在服务器上完全不难实现。没有任何内容通过网络发送，可以揭示密码是什么，只是允许客户端向服务器证明他们有正确密码的信息。

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

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

附录：这个答案差不多十年了。现在，无论出于何种其他考虑因素，您确实都在使用HTTPS。

Answer 2

当与SSL（https：//）网站一起使用时，HTTP基本身份验证非常安全，因为包括凭据在内的所有HTTP流量都将被加密。但有一个主观缺点是，当使用此方法时，您的用户需要与浏览器的身份验证弹出窗口进行交互才能登录您的网站。

Answer 3

要明确，唯一可行的方法是通过HTTPS。

但是，既然我认为这不是一个选项，我也假设你正在寻找一个“完全管理的登录”系统，我继续：

除了HTTPS之外，可以使用JavaScript在客户端进行密码的安全散列，以防止通过线路显示纯文本密码，但这是只有半个解决方案。

这种方法的问题是：

1. 重播攻击仍然是一个可行的选择。
2. 只有启用了JavaScript的用户才能以这种方式进行身份验证。




另一种方法是更复杂的挑战/反应机制：

1. 发送“挑战”以及登录页面。
2. 计算密码+质询客户端的哈希值。
3. 提交登录信息。
4. 计算服务器端密码+质询的哈希值（在页面请求中不得信任），并进行比较。

以及那个问题：

1. 只有启用了JavaScript的用户才能以这种方式进行身份验证。
2. PLAINTEXT密码必须存储在服务器上以验证质询响应，并且必须在磁盘上加密或以其他方式受到保护。




现在，公平地说，问题＃2没有听起来那么危险。实际上，当您使用HASH身份验证时，哈希本身会提升到“密钥”的级别。

此时使用cookie存储随机生成的登录ReferrenceID是相当安全的，类似于其会话ID，但服务器可能希望使用引用IP加密作为IV或KEY，以防止其他用户劫持ReferrenceID。

无论如何，我希望这会为你的设计提供一点方向。

Answer 4

使用HTTP时，HTTP身份验证并不安全。

Answer 5

首先，除了无法实现真正​​的“注销”功能之外，HTTP Auth对SSL是安全的。用户需要关闭他们的浏览器，这非常糟糕。

其次，您需要在所有情况下都使用HTTPS以确保其安全，之后您将获得类似Basic Dih的类似内容，例如“摘要”和“NTLM Auth”。

Answer 6

当您使用https时，您还可以在客户端的浏览器中安装证书并验证。 myopenid为其OpenID帐户提供此功能。我有一个，它的效果非常好（从客户端的角度来看）。

Answer 7

与HttpOnly Cookies结合使用SSL加密以帮助防止XSS是使用Cookie的最佳选择。不过，我不会说它是防弹的。