有没有办法通过 Web 获得持久的（无论多小）客户端存储？

Posted 2023-04-01

【中文标题】有没有办法通过 Web 获得持久的（无论多小）客户端存储？

【英文标题】：Is there any way to have persistent (regardless of how small) client-side storage via the web?

【发布时间】：2009-08-20 18:39:09

【问题描述】：

好的，既然你们都不喜欢我的问题，让我改一下。

用户登录到 html 表单。使用 javascript，他们的密码在本地进行哈希处理（也加盐）。服务器知道密码+盐应该是什么，用户已经注册，blahblahblah。现在用户请求一个页面。服务器向用户发送一个随机 ID。当用户加载下一页时，这个随机 ID 会附加到他们本地存储的密钥上，经过哈希处理，然后将其发送到服务器。服务器知道他们的密钥是什么和随机 ID，执行相同的哈希并进行比较。如果它们匹配，恭喜，它来自正确的计算机。如果没有，那么有人一直在嗅探您的 TCP/IP 流量。

所有这些显然没有 SSL，否则这将是高度冗余的。

我的问题 - 如何在客户端 PC 上存储密钥？

原帖：

你好；

我正在开发一个 php 内容管理系统，并想出了一个安全的登录系统。唯一的问题是它需要某种形式的客户端存储（对于一个非常小的密钥，长度为 40 个字符） - 否则用户必须在每次页面加载时输入他们的密码。

有没有一种方法可以让我使用 PHP 或 JavaScript 在客户端的 PC 上存储一个 40 个字符的小字符串，以便稍后检索它？

编辑：Cookie 不是一种选择。这 40 个字符的字符串不能离开客户端的计算机，并且所有设置的 cookie 都与每个 HTTP 标头一起发送。

我重复一遍 - COOKIES 不安全，不是一个可行的选择。

让我像这样修改它 - 客户端提交一个 HTTP 表单。使用某些脚本语言（例如 JavaScript），密码会从表单中删除，不会发送到服务器，加密并保存在客户端，我可以检索和验证（通过使用发送给用户的密钥对其进行散列）服务器）。这个验证被发送到服务器，不是密钥。

【问题讨论】：

en.wikipedia.org/wiki/HTTP_cookie

您可以存储在客户端计算机上的任何内容都可以从客户端计算机上复制到其他人的计算机上。我想说这与“安全”登录完全相反。

您能解释一下您要解决的问题，而不是您想出的解决方案吗？另外，你为什么说 cookie 不安全？你能不能把散列密码存储在 cookie 中？应该不错吧。

因为他试图做一些大多数人认为愚蠢的事情。

@Breakthrough session_regenerate_id() 如果您认为无法保证会话安全。你的提议听起来很荒谬。如果您永远不希望它“通过互联网”传输，那么将某些东西保留在客户端的机器上有什么好处？ 99% 的网站都可以正常使用基于会话的身份验证。

【参考方案1】：

已经有一个基于浏览器的系统使用密钥来保护数据传输。它被称为 SSL。

【讨论】：

如果我可以使用 SSL，我早就可以避免所有这些令人头疼的问题了。

所以你必须编写一些安全的东西，即使是针对 MITM 会话劫持，而不使用 SSL？为什么？

因为类似的东西早就应该在各种网站上实现了。吓到我，坐在报告厅里，用一些简单的wifi数据包嗅探工具，我得到了多少信息。

我认为这是 wifi 的问题，而不是 Web 的问题。这就是我在连接不安全时使用 ssh -D 的原因。我认为这里最合理的方法是在登录时使用（可选！）客户端质询-响应，并确保被劫持的会话密钥不能做任何不可逆转的破坏性事情。 （例如，更改密码/电子邮件时再次要求输入密码）

【参考方案2】：

您可以使用几种不同的技巧来保持客户端的状态，您可以保持***框架并在那里存储一个 javascript 变量。

您可以使用Flash本地“SharedObject”，

Silverlights 的独立存储

或 Google Gears 中的等价物。

但是..

不要遵循这种思路。您需要 SSL。你不会构建安全的东西，你会构建一个让你或使用你的应用程序的人开枪的东西。

【讨论】：

我喜欢***框架的想法... +1

【参考方案3】：

首先我会回答“我可以在不使用cookie的情况下存储客户端数据吗”的问题：

您可以使用 Flash SharedObject，但当然需要 Flash，并且用户必须单击确认框才能使用它。 HTML5 具有客户端数据库，因此为您提供了另一种新兴选择。 在客户端使用 Google Gears 并使用他们的本地 database API

但是-出于您的目的，您可以设计一个登录表单，该表单不传输密码，而是发送密码的哈希值。您的 PHP 脚本将发送一个包含秘密盐值的表单，然后您有一些 javascript 挂钩到提交事件并用盐化哈希替换输入的密码。

【讨论】：

但问题是，如果攻击者正在记录您的流量，他会看到盐被发送到客户端...

知道盐不会让您登录，因为您仍然需要密码。您可以等到用户登录后才能看到加盐密码，但如果您确保只能在无法重播该密码后才能使用加盐密码。

【参考方案4】：

我不是 PHP 开发人员，但我建议您搜索预先存在的身份验证系统。它们通常会比您编写的内容更安全（因为这将是它们的主要目的）。它还可以让您查看代码并了解他们是如何做到的并找出原因。

编辑：您几乎总是想要在服务器上处理身份验证。以 cookie 或 url 参数的形式将会话信息传输给用户是可以接受的，但实际处理应在服务器上完成。否则，您将面临重大风险。

【参考方案5】：

如果您想在浏览器访问之间保存它，请使用 cookie。它将存储在客户端的机器上。

如果您想将会话保存更短的时间，请使用会话。它将存储在网络服务器上。

【讨论】：

会话 ID 通过 cookie 传播给客户端。 us3.php.net/manual/en/session.security.php

好吧 cookie == 写入用户的磁盘，我不知道您将如何避免写入用户的磁盘并以某种方式在客户端计算机上保存状态。人们对启用 cookie 感到非常害怕，祝他们好运，让他们能够对自己的机器进行写访问。

【参考方案6】：

如果您想创建从未在互联网上传播过的东西，您基本上必须用 JavaScript 来完成。

首先，创建一段代码，用于启动 Google Gears 之类的东西。使用 Google Gears 中的数据库来存储密钥。

接下来，在其余页面上，使用一段 javascript 检查 Google Gear 数据库中的密钥。如果密钥无效，请删除密钥，重定向用户，让他们重新登录。

【讨论】：

到目前为止，您已经找到了最接近我正在寻找的东西。有没有不需要安装的跨浏览器解决方案？

至少在 HTML5 之前不会。然后还有支持的旧浏览器。

大多数浏览器除了查看页面外并没有做任何事情。 Javascript 来了，让页面正常工作。 HTML5 将允许浏览器无需安装即可存储内容。但 HTML5 是一种较新的协议，这意味着它不会在所有浏览器上都受支持。

【参考方案7】：

Cookie 是执行此操作的方法，但您不会在 Cookie 中存储任何密码，这（几乎）是一个命令；-)。

您可以使用会话在服务器端的页面加载之间存储信息。 http://fr.php.net/manual/en/book.session.php

【参考方案8】：

补充一下 Bryan 所说的，如果您可以使用 HTML 5 规范，那么您可以利用本地存储。

http://ajaxian.com/archives/webkit-does-html5-client-side-database-storage

【参考方案9】：

我发现你的方法有问题。可以嗅探初始 JavaScript 的首次加载，因此盐算法不受黑客攻击。那么ID也是“公开的”。 IE。好像你有下一个架构（如果我错了，请纠正我）：

password + SHA1 => hashed password
hashed password + (ID from server) + (salt from server) => mega hashed password

我真的很难理解为什么“mega hashed password”比 hashed 更安全。