我使用的硬件系统传统上通过在物理键盘上输入一个简短的数字密码来验证用户。尽管密码熵很小,但这个系统已经被证明是相当健壮的,因为已经建立了检测蛮力(重复错误的密码输入)的机制。每个用户都有一个相关的名称字符串和数字密码。名称字符串仅用于管理目的,而不用于身份验证过程。因此,要弄清楚:用户与系统交互的唯一方法是在现场,走到物理键盘,此时他们只有X尝试输入正确的数字密码。
我们现在希望通过一个完整的HTTPS服务器和REST来介绍远程移动设备对系统的访问。由于该系统是一个非常受限的裸金属嵌入式平台,实现HTTPS服务器是可能的(并且现在已经实现了),但是我认为在这个时候容纳基于令牌的方案(如OAuth )太困难了,因此我希望依赖TLS加密的基本身份验证。
为了符合标准,远程用户每次使用手机应用程序时都需要提供一个密码。产品管理将不可避免地规定,现有的遗留用户名字符串和密码用于通过HTTPS REST远程验证用户(换句话说,当他们使用电话应用程序时),但显然现有的短数字密码很容易被强制使用,我怀疑在HTTPS上实现锁定机制可能是困难和麻烦的。更改现有系统以使用更长、更复杂的密码不是一种选择,因为现有的遗留系统将不支持这些密码。因此,我的结论是,为了远程访问,每个用户都需要一个次要的、更高熵的密码,以及他们遗留的数字密码。然而,我怀疑产品管理部门不会喜欢这样一个事实,即用户现在必须记住并使用单独的远程访问密码。
我所想出的解决办法如下:
这样,就有了一个高熵的密码用于远程访问,降低了基本暴力的风险。该应用程序现在只使用简短的遗留密码从本地存储中检索HTTPS密码。在某种意义上,我认为这就像通过一个单独的通信通道预先共享一个“salt”(在本例中是用户从硬件LCD读取密钥)。它实现了最终目标,即给用户的印象是,他们通过常规数字密码访问系统(通过应用程序)。
我看到的一个缺陷是,它依赖于存储远程访问密钥的移动设备。在这个时候,我还不知道会有多大的漏洞。我想的是,如果基本身份验证过程需要将远程密钥(永久存储)和短数字密码(用户每次输入,从未存储)连接在一起,那么这意味着设备上永久存储的任何内容都不足以让攻击者在不需要进一步工作的情况下获得访问。
在考虑到我的限制后,我提出的建议是否有任何缺点或改善的机会?
发布于 2015-11-08 17:37:28
您的解决方案听起来不错,正如您提到的本地存储所存在的漏洞。由于长密码是“盐渍”与短PIN,您仍然容易受到攻击,如果长密码是已知的。
避免这种情况的一种方法是使用客户机TLS证书,该证书将根据服务器的请求提供。这样做的优点是不能检索存储的证书(无需付出一定的努力)和整个证书安全动物园(特别是吊销)。
https://security.stackexchange.com/questions/104954
复制相似问题