在 ipad 等离线设备上对用户进行身份验证

信息安全 Web应用程序 验证 移动的
2021-09-12 06:36:35

我们希望在平板电脑上运行的 webapp(浏览器内的 JavaScript/HTML)中验证用户身份,但希望能够在设备从网络离线时执行此操作。我意识到这已经不是超级安全的环境,但我不想通过糟糕的身份验证方法降低它的安全性。

该环境是在公司网络内的 iPad 上运行的 Web 应用程序。用户使用并共享 iPad(没关系),但我们需要验证 webapp 的当前用户是否有效,从而阻止可能拿起设备的随机人员/工作人员。网络连接性不是 100%,这不能轻易改善。我们的目标是出于审计目的的验证,而不是安全控制,我们需要证明用户 X 在 iPad 上执行了该操作。

当我们在网络上时进行身份验证很容易,将数据包发送到服务器并获得是/否响应。但是,如果我们处于离线状态,我们将无法这样做。我可以将所有用户和密码哈希下载到 iPad,但这似乎是个坏主意——我刚刚导出了密码文件,这感觉不对。

下一个想法是单独的在线和离线密码,但这对用户来说似乎太难了。我们还考虑过信任登录并推迟验证,直到我们重新上线,但这存在业务/应用程序问题。目前,我们对主应用程序使用普通密码,但在 iPad 上使用可视密码,基本上是两个密码,但呈现不同,因此用户不会认为它是相同的。拥有两个密码意味着我们可以拥有不同的策略、控制和审计。

有没有更好的方法来做到这一点?

1个回答

我敢肯定你不是故意的。但目前这是一个充满政治色彩的问题,也是一个技术问题。一些appsec 专家认为,在 javascript 中实现的加密本质上是有缺陷的;他们提出了一些很好的论据,其中只有少数是不适用的,因为 javascript 只能在 Intranet 上访问,而且只能在一种设备上访问。

在没有网络连接的设备上对用户进行身份验证意味着在设备上存储密码哈希。你可以用加密技术做很多聪明的事情,但你无法绕过它。您可以做的最好的事情是使用强大的基于密码的密钥派生函数,了解这可能仍然使您很容易受到攻击,并使用补偿控制:物理安全性和策略,使从 HTML5 本地存储中提取哈希变得困难/有风险并将它们带回家进行离线破解。

这就留下了您在本地存储哪些密码哈希的问题。这听起来有点像你只对不可否认的行为感兴趣:

我们需要证明用户 X 在 ipad 上执行了该操作。

如果您使用身份验证的唯一原因是不可否认,并且单个可否认操作构成系统的完全破坏,那么为每个用户设置两个单独的密码没有多大意义。如果您还有其他安全目标,保留两个单独的密码可能是值得的;尤其是如果用户合规性不是问题——而且你的 UI 解决方案听起来确实有效。