如何存储和验证从PIN /密码中随机选择的数字

时间:2010-08-02 13:49:37

标签: security authentication encryption hash passwords

如果我有一个用户6位数的PIN(或n个字符串),并且我希望验证从PIN(或x字符)中随机选择的3个数字作为“登录”程序的一部分,我将如何存储数据库中的PIN或PIN的某些加密/哈希版本是否可以验证用户身份?

思想:

  1. 将PIN存储在可逆位置 (对称或非对称)加密方式,解密数字检查。
  2. 存储PIN的一系列散列排列 ID,链接到'随机 数字'被选中,例如:
    • ID:123 =数字1,2,3的哈希
    • ID:416 =数字4,1,6的哈希
  3. 问题:

    1. 密钥安全:假设密钥是 '受保护',应用程序不是 财务也不高度批评,但是 是'高容量'。
    2. 创建一个 大数量的哈希值 排列是令人望而却步的 高存储(16字节x几个 排列)和耗时可能是矫枉过正的
    3. 还有其他选择,问题或改进吗?

      是的:我知道以可逆的方式存储密码/ PIN是“有争议的”,理想情况下不应该这样做。

      更新

      只是为了澄清: 随机数字是我考虑避免键盘记录器的方案。 2.不可能尝试超过有限次数的重试。 3.其他元素有助于保护和验证访问权限。

6 个答案:

答案 0 :(得分:2)

因为用于存储密码/密码短语的任何加密方案要么过于昂贵,要么容易破解我只是简单地将其存储在简单的textr中并确保数据库和服务器安全性是划伤。

您可以考虑使用一些轻量级加密方案来隐藏数据库的随意浏览器中的密码,但是,您必须承认任何方案都有两个基本漏洞。一个 - 你的程序将需要一个密码或密钥,它必须存储在某个地方,并且几乎像在纯文本中提供的实际密码一样容易受到窥探,而且,如果你有合理数量的用户,那么有权访问加密密码的黑客有很多“线索”来帮助他的暴力攻击,如果你的网站向公众开放,他可以在你的数据库中插入任意数量的“已知文本”。

答案 1 :(得分:1)

由于6C3是20而10C3是120,我会在我猜测的1/6时得到假阳性(被认证)。

无论您如何存储令牌,此方案仅比没有身份验证稍微好一些。

答案 2 :(得分:1)

我完全赞同msw但这个论点只对(或大部分)六位数方案有效。对于n-char方法,假阳性率(有时......)要低得多。一个改进是随机字符必须以与密码中相同的顺序输入。

另外我认为存储散列排列会使用一些强力方法找到密钥相对容易。例如,测试并组合三个字符的不同组合,并根据存储的哈希检查这些组合。这样做会破坏首先对密钥进行哈希处理的目的,这样你就可以存储加密密钥。

另一个完全不同的论点是,您的用户可能会对这个奇怪的登录过程感到非常困惑:)

答案 3 :(得分:1)

一种可能的解决方案是使用Reed-Solomon(或类似的东西)来构造n-of-m方案:生成n次多项式f(x),其中n是登录所需的位数,并通过评估f(x)处的x=1..6来生成图钉数字。数字组合成为您的完整引脚。然后可以使用这些数字中的任何三个(以及它们的x坐标)来内插多项式常数。如果它们等于原始常量,则数字是正确的。

当然,最大的问题是用多项式常数算法形成一个数字0..9的字段。在这种情况下,普通算术不会削减它。我的有限场太生锈了,不记得是否有可能。如果每位数为4位,则可以使用GF(2^4)来克服此缺陷。此外,您无法选择PIN码。它需要分配给您。最后,假设您可以解决所有问题,n方案中只有1000个不同的多项式,并且它太小而无法保证正确的安全性。

无论如何,我认为这不是一个好方法,但我想在混合中添加一些不同的想法。

答案 4 :(得分:1)

您说您还有其他身份验证元素。如果您还有密码,则可以执行以下操作:

  1. 要求输入密码(密码仅作为哈希存储在您身边)
  2. 首先根据存储的密码哈希检查输入密码的哈希值
  3. 成功后,继续,否则返回1
  4. 使用输入(未散列)密码作为对称加密PIN的密钥
  5. 询问PIN的随机数字
  6. 这样,PIN就会被加密,但密钥不会以明文形式存储在您身边。我银行的在线门户网站似乎就是这样做的(至少我希望PIN是加密的,但是从用户的角度来看,登录过程就像上面描述的那样)。

答案 5 :(得分:0)

  • 密钥是“受保护”
  • 该应用程序不具有财务或高度 关键的,
  • 该应用程序是“高容量”。
  • 创建大量哈希值 排列是令人望而却步的 高存储(16字节x几个 排列)和耗时 可能有点矫枉过正
  • 随机数字是我的计划 考虑避免使用键盘记录器。
  • 无法尝试更多 而不是有限的重试次数。
  • 其他元素有助于保护和安全 验证访问权。

您似乎在争论将PIN存储在明文中。我说去吧。您基本上是在描述质询 - 响应身份验证方法,而服务器端的明文存储对于该用例来说很常见。

与此类似的是一次性密钥或秘密密钥矩阵。不同之处在于用户必须保持/拥有垫以便访问。好处是,只要您获得足够安全的密钥分发,您就可以非常安全地使用键盘记录程序。

如果您想使基质/垫的曝光不会造成单独的损害,请让用户使用短的(3-4号)PIN码,并保持敏感的锁定机制。

矩阵示例:

  1  2  3  4  5  6  7  8
A ;  k  j  l  k  a  s  g
B f  q  3  n  0  8  u  0
C 1  2  8  e  g  u  8  -

挑战可能是:“输入您的个人识别码,然后输入矩阵中B3方格中的字符。”

回应可能是: 98763