HTML5 离线认证

Question

我正在寻求有关如何最好地控制对主要离线使用的 HTML5 应用程序的访问的建议/批评。

应用程序结合使用 IndexedDB、本地和会话存储来存储数据，以便可以离线使用。数据/页面通过 HTTPS 提供。

目的是最大程度地降低平板电脑/PC 丢失/被盗时查看数据的风险。

目前，该应用程序使用 Stanford Javascript Crypto 库对用户/密码进行加密，然后如果用户能够成功通过服务器验证，则将其保存到本地存储中。如果应用程序随后脱机，则用户必须针对本地存储中的加密用户/密码进行“本地”身份验证。

此外，如果用户能够成功通过服务器身份验证，则未加密的用户/密码将存储在会话存储中。这样做是为了让应用程序可以定期尝试重新建立与服务器的联系并“看似”地重新进行身份验证，而无需用户重新输入他们的凭据。

我知道一些关于客户端加密错误的帖子/讨论请参阅 http://www.matasano.com/articles/javascript-cryptography/ 和 http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ 和 .nczonline.net/blog/2010/04/13/towards-more-secure-client-侧面数据存储/ +其他。但是我不确定这些论点在这种情况下如何应用。

鉴于需要离线存储数据，我正在寻找对这种方法的批评。如果有更好的方法，请详细说明。

谢谢

Answer 1

身份验证与安全存储

我将从一个重大的设计问题开始：您似乎在处理该问题时好像是关于身份验证，其中（可能是恶意的）用户需要向您的应用程序证明她确实是有效用户。但实际上您正面临存储问题，因为如果计算设备被盗，整个运行时环境（包含您的应用程序正在使用的所有敏感信息）都在攻击者手中。在 javascript 应用程序的情况下，离线数据和代码的分析比在某些仅二进制代码的情况下更加舒适。

例如，如果我想攻击您的应用程序，我会首先查看会话存储（cookie？只需使用浏览器界面查找它们），看看是否可以在那里找到用户名和密码。如果不是，我将遵循用于解密本地存储中的密码的代码（可能使用 javascript 调试器）。您描述应用程序的方式似乎函数可以在没有用户提供的密钥的情况下对其进行解密。也许我可以通过将if(authenticateUser()) 更改为if(true) 之类的内容来注释掉用户的本地身份验证。

因此，您真正需要做的是使用根本不存储在客户端的密钥加密所有敏感的本地数据。例如，每次访问您的应用程序时都要求用户提供解密密钥，使用该密钥解密本地存储的数据（并加密您存储的每个新数据）并在一段时间不活动后将密钥扔掉强>。或者，您可以在用户每次访问您的应用程序时对服务器进行身份验证，并从那里检索解密密钥，并在一段时间不活动后将其丢弃。

此时，javascript 环境的选择确实会妨碍您的事业，因为您无法强制运行时环境在您希望解密密钥消失时丢弃它。即使使用 C 应用程序也很难，因为您必须小心地将 RAM 换到 HDD 上。根据您的应用程序使用的信息的敏感程度，可能足以要求用户在完成后关闭浏览器并假设攻击者没有足够的动机在浏览器换出的 RAM 中寻找密钥。

本地保存登录数据

由于它是您使用的最敏感信息，因此您永远不应将用户登录信息存储在客户端上。而是对服务器进行一次身份验证，并从中检索身份验证令牌以供将来交互。这基本上与会话 cookie 相同，并在一段时间后过期（如果它根本没有过期，它与密码一样好）。

Answer 2

我现在已经实现了一个解决方案，我将在下面描述它以防它对其他人有用。我确实明白这不是我的问题的“答案”，即不提供批评，但鉴于应用程序必须“离线”工作以及无缝重新验证的要求，我看不出如何实现@Perseids 答案，尽管我很欣赏对话（来自@SilverlightFox 和@Perseids）。

如果有一种解决方案可以在满足我的问题中概述的要求的同时不必“离线”存储用户的凭据，我很想听听。

---

应用程序必须能够在应用程序“在线”和“离线”时对用户进行身份验证。对于“在线”应用程序，通常会采用会话令牌解决方案，即仅将会话标识符存储在客户端（通常在 cookie 中）而不是用户的凭据。然而，用户的凭据必须存储在客户端上（也许有人会想出一个聪明的替代方案？）以便在应用程序离线时可以强制执行安全性，即允许用户在离线时进行身份验证并解密/加密 IndexedDB 数据。为了使应用程序更加安全，用户的用户名和密码以加密形式存储。一些敏感的 IndexedDB 数据也以加密形式存储。因此，即使恶意用户要获取具有应用程序缓存实例的计算机或平板电脑，他们也只能以加密形式查看用户名、密码和数据（前提是用户已注销或关闭浏览器）。

不幸的是，目前似乎没有任何“标准”协议来保护 HTML5 离线应用程序。几乎所有文献都警告不要在客户端存储用户凭据或任何敏感数据。然而这是一个悖论，因为此应用程序必须在离线时工作，因此数据必须离线存储。

这里实现的安全协议有两个密钥，虽然一旦第一个密钥被破解，就很容易获得第二个密钥。在第一级中，用户的密码使用他们自己的密码作为密钥进行加密，同时他们的用户名作为盐被反转。还有第二个密钥，“数据加密密钥”，在成功验证服务器后从服务器返回。此密钥用于加密用户名和任何 IndexedDB 数据。这个“数据加密密钥”又使用用户的密码进行加密。因此，如果攻击者能够解密用户的密码，他们就可以轻松地使用密码来解密“数据加密密钥”，然后使用解密的“数据加密密钥”解密用户的用户名和任何加密的 IndexedDB 数据.只有用户名、密码和数据的加密形式需要永久存储在客户端上，因为通过使用在登录屏幕中输入的用户名和密码，就可以解密任何持久化的数据。

但是，在登录后，用户名和密码以未加密的形式存储在客户端的会话中，以便 1) 应用程序可以定期重新与服务器进行身份验证，如果存在间歇性连接和2) 随时检索解密后的数据加密密钥，以便能够查询/保存IndexedDB数据并在必要时对其进行解密/加密。如果 1) 不是必需的，则只需将数据加密密钥存储在会话中。如果用户没有注销或没有关闭浏览器，这会导致漏洞，因为恶意用户将能够以解密形式查看用户的密码和用户名（使用调试工具）。然而，这并不比发生在让用户能够更改密码的传统在线应用程序中发生的同样事情差多少，尽管通常传统的在线应用程序具有会话超时，因此恶意用户只有有限的时间采取行动。此外，如果浏览器崩溃，通常它会为用户提供使用会话信息恢复之前的窗口/选项卡的选项，因此应该正确关闭浏览器。

上面采用的协议几乎可以肯定没有遵循最佳实践。例如盐不是随机的（用户名颠倒），可能很短，容易受到字典攻击，同样可能适用于密码（密码的强度是服务器的函数），没有密钥拉伸例如PBKDF2。但是，鉴于施加的限制，我看不出如何遵循“最佳实践”并满足要求。可以稍微改进散列，例如改进盐，可能是用户名和特定于站点的字符串的组合，但即使这样也需要 javascript 中的逻辑，这可以被坚定的攻击者理解。 Javascript 可以被混淆，但这也只会让它变得更加困难，但并非不可能，任何能够破解加密密钥的人都不会发现混淆 Javascript 是一个很大的障碍。也许未来有一些来自浏览器的聪明的内在内置支持将有可能实现显着的改进。