Encryption 如果攻击者拥有原始数据和加密数据，他们能否确定密码短语？

如果攻击者有几个不同的项目（例如：电子邮件地址），并且知道每个项目的加密值，那么攻击者能否更容易地确定用于加密这些项目的机密密码短语？也就是说，他们能在不诉诸暴力的情况下确定密码短语吗

这个问题听起来可能很奇怪，所以让我提供一个用例：

用户使用其电子邮件地址注册到站点

服务器向该电子邮件地址发送确认URL（例如：）

攻击者可以猜测确认URL，因此可以使用其他人的电子邮件地址注册并“确认”，而无需登录该人的电子邮件帐户并查看确认URL。这是一个问题

我们将通过加密密码发送电子邮件地址，而不是在URL中发送纯文本

（我知道攻击者仍然可以截获服务器发送的电子邮件，因为电子邮件是纯文本的，但请注意。）

如果攻击者随后注册了多个免费电子邮件帐户，并看到多个URL，每个URL都有相应的加密电子邮件地址，那么攻击者能否更轻松地确定用于加密的密码短语

替代解决方案

我可以改为发送一个随机数或他们电子邮件地址的单向散列（加上随机盐）。这消除了存储秘密密码短语的麻烦，但这意味着我需要将该随机数/散列存储在数据库中。上述原始方法不需要在数据库中存储

---

我倾向于使用数据库中存储的单向散列，但我仍然想知道答案：拥有多个未加密的电子邮件地址及其加密的对应地址是否可以更容易地确定使用的密码短语？

是的，确实可以更容易地确定使用的密码短语。通常，攻击者拥有的信息越多，他们的工作就越容易。这个具体的例子叫做a。

您所描述的是a。经典密码非常容易受到这种攻击，但现代密码的设计就是为了抵抗这种攻击

---

你会想读一点关于加密的知识。

尽管通过一些研究，你可能会选择一种足够强大的加密方法来抵抗已知的明文攻击，但仅仅避免在数据库中存储散列值真的值得吗

使用单个密码短语加密所有注册请求似乎是在添加一个不必要的单点漏洞：如果攻击者以某种方式破解该密码短语，他们可以注册任意数量的帐户。另一方面，如果您为每个新帐户请求生成一个一次性哈希（例如，电子邮件地址+随机数）来验证确认URL，则即使是拦截帐户a的确认电子邮件的黑客也无法访问B、C或D

---

您可能希望在数据库中存储有关确认过程的一些状态信息：确认URL的有效期可能有一个时间限制。

您需要的不是加密，而是身份验证。在发送给客户的链接中，不仅包括他们的电子邮件地址，还包括时间戳和所谓的MAC，这是一个基于对称密钥的身份验证字段。MAC应验证电子邮件地址和时间戳。64位HMAC-SHA1应该可以。当您收到链接时，检查时间戳是否在过去不太远，MAC验证；然后你就知道你生成了链接

---

MAC被设计用于抵御攻击者选择消息并请求相应MAC的攻击，因此您不必担心MAC等同于“已知明文攻击”。

有一种情况下，答案是肯定的！！！这就是如果使用流密码，比如RC4

RC4本质上是一个随机数生成器，它将明文与从密钥派生的“密钥流”进行异或运算：

P0^K0=C0
P1^K1=C1
P2^K2=C2
.
.
PN^KN=CN

如果您同时拥有明文和密文，则可以执行以下操作：

C0^P0=K0
C1^P1=K1
C2^P2=K2

---

等等。正如您所看到的，您得到了密钥流。不是密钥，而是由密钥生成的流。

但是对于设计良好的加密方法来说，它仍然很难做到这一点。现代密码设计不仅可以抵抗已知的明文攻击，还可以抵抗自适应选择密文攻击。假设您的原语很弱而设计您的协议是一个很大的错误；选择受信任的原语。为什么不通过应用像OpenId这样的联合身份解决方案来消除您的整个问题？您的替代解决方案不需要额外的表，只需要现有表中已存储电子邮件的额外列address@Gareth你说得对，我已经更新了这个问题。谢谢事实上，我认为由于“随机”散列/秘密生成不当而导致的漏洞至少与引入单个密钥的任何风险一样（如果不是更多的话）有可能。哈，太好了！我考虑的更多的是三重DES或AES，而不是XOR，但感谢提示。RC4已损坏，不应使用。现代流密码将有两个参数，密钥和“nonce”。同一个密钥可以多次使用，只要不与特定密钥重复使用nonce。即使您使用的是三重DES或AES，它们也是分组密码；当您使用链接模式时，您可以有效地使用它们来构建流密码，因此同样的考虑也适用。一种流行的链接模式是CTR模式，它使用XOR将流与明文相结合。所有安全链接模式都要求不重复使用nonce，而不仅仅是CTR。“所有安全链接模式都要求不重复使用nonce”-这就是为什么“nonce”==“number once”：-）