密码系统要求提供单个字母 - 它们存储什么？ [英] Password systems which ask for individual letters - what do they store?

问题描述

一些（尤其是银行）密码系统要求您输入密码之外的三（指定）字母才能登录。
这应该会击败键盘记录程序，并且可能会导致嗅探重放攻击（对于未加密的会话） 。

显然，这样的方案无法使用普通密码散列工作，因为您需要知道整个密码才能计算散列。

这些系统通常存储在服务器端以实现这一功能吗？

密码是以明文形式存储的，还是以一个单独的散列的每个字母，或什么？

解决方案

正如你正确地注意到，标准密码散列方案不会工作，如果身份验证仅使用密码的子字符串完成。有多种方式可以实现这样的系统：

将密码存储为纯文本：

• 简单且易于实现


• 如果数据库受到威胁，则不安全。不符合需要散列或加密的密码存储的规定（但使用低级别数据库加密可能会得到这些）。
  

存储密码，解密以检查：

• 如果加密密钥也被泄露， 。


• 可以通过使用专用的硬件安全模块或单独的认证服务器，它可以存储密钥并提供加密和子串验证的黑盒接口。
  

存储所有（或足够多）可能的子字符串的散列值：

• 需要比其他解决方案多得多的存储空间。
  
• 如果数据库受到攻击，密码仍然可以通过蛮力恢复，因为每个子字符串可能会被单独攻击。

使用 k -out-of- n 阈值秘密共享 ：

• 需要的空间少于存储多个散列的空间，但不仅仅是以普通或使用可逆加密存储密码。 li>
  
• 无需为子字符串验证解密密码。


• 如果数据库受到攻击，仍然容易受到强力攻击：任何可以猜测 k 密码的字母可以恢复其余部分。 （实际上，在某些实现中， k -1可能就足够了。）
  

最终，所有如果数据库受到威胁，这些方案会遭受强力攻击的弱点。其根本原因在于，典型密码的三个字母子串中（或者甚至是特别强的一个）的熵没有太多的熵，因此不需要许多猜测来破解。 / p>

这些哪一个最好？这很难说。如果我有 选择这些方案之一，我可能会使用强对称加密（如AES）加密存储，并使用单独的服务器或HSM来处理加密和验证。这样，至少，攻击者损害前端服务器将无法复制数据库并脱机攻击它（尽管如果它没有实现有效的速率限制，它们仍然可以对HSM进行强力攻击）。

但是，我认为仅使用部分密码进行身份验证的想法存在严重缺陷：它并不能真正实现安全性，应该是，除了一些特别受限的攻击情况（例如窃听者只能观察一个认证事件，并且不能继续尝试直到他们得到相同的挑战），但它从根本上削弱了安全性，减少了所需的信息量成功认证。有很多更好的解决方案，例如 TAN ，以应对部分密码认证的安全性问题地址。

Some (especially bank) password systems require you to enter three (specified) letters out of your password to log in. This is supposed to defeat keyloggers, and possibly wire-sniffing replay attacks (for unencrypted sessions).

Clearly, there's no way such a scheme can work using ordinary password hashing, since you'd need to know the whole password to compute the hash.

What do such systems commonly store server-side to make this work?

Do they store the password in plaintext, or maybe a separate hash of each letter, or what?

解决方案

As you correctly note, standard password hashing schemes won't work if authentication is done using only a substring of the password. There are a number of ways that such a system could be implemented:

Store the password in plain:

• Simple and easy to implement.
• Insecure if the database is compromised.
• May not comply with regulations requiring hashed or encrypted password storage (but using low-level database encryption might get around that).

Store the password encrypted, decrypt to check:

• No more secure than storing it in plain if the encryption key is also compromised.
• May satisfy regulations forbidding password storage in plain.
• Could be made more secure by using a dedicated hardware security module or a separate authentication server, which would store the key and provide a black-box interface for encryption and substring verification.

Store hashes of all (or sufficiently many) possible substrings:

• Needs much more storage space than other solutions.
• Password can still be recovered fairly easily by brute force if the database is compromised, since each substring can be attacked separately.

Use k-out-of-n threshold secret sharing:

• Needs less space than storing multiple hashes, but more than storing the password in plain or using reversible encryption.
• No need to decrypt the password for substring verification.
• Still susceptible to brute force attack if database is compromised: anyone who can guess k letters of the password can recover the rest. (In fact, with some implementations, k-1 letters might be enough.)

Ultimately, all of these schemes suffer from weakness against brute force attacks if the database is compromised. The fundamental reason for this is that there just isn't very much entropy in a three-letter substring of a typical password (or, indeed, of even a particularly strong one), so it won't take many guesses to crack.

Which of these is best? That's hard to say. If I had to choose one of these schemes, I'd probably go for encrypted storage using strong symmetric encryption (such as AES), with a separate server or HSM to handle encryption and verification. That way, at least, an attacker compromising a front-end server wouldn't be able to just copy the database and attack it offline (although they could still mount a brute force attack on the HSM if it didn't implement effective rate limiting).

However, I'd say that the whole idea of using only part of the password for authentication is deeply flawed: it doesn't really deliver the security benefits it's supposed to, except in a few particularly constrained attack scenarios (such as an eavesdropper that can only observe one authentication event, and cannot just keep trying until they get the same challenge), yet it fundamentally weakens security by reducing the amount of information needed for successful authentication. There are much better solutions, such as TANs, to the security concerns that partial password authentication is supposed to address.

这篇关于密码系统要求提供单个字母 - 它们存储什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！