我在PHP中使用sodium_crypto_secretbox和sodium_crypto_secretbox_open函数(目前使用PHP5.6,使用paragonie/sodium_compat)。
如果用户拥有密码文本,现在和解密的纯文本,他们能确定用于加密信息的密钥吗?
上下文:我正在加密用户的登录令牌(存储在机器上的cookie ),并将其用作CSRF令牌。当提交时,CSRF令牌必然包括用于解密的nonce。CSRF令牌在提交表单帖子时被解密和验证,以防止CSRF攻击。
我关心的不是那些无法访问cookie的CSRF攻击者,而是密钥本身。为了简单起见,对软件中的其他加密功能使用相同的密钥是有用的,但是如果可以通过这些信息很容易地公开,我就不能。合法用户可以看到CSRF令牌和cookie:他们能发现密钥吗?
发布于 2018-06-30 20:15:14
如果用户拥有密码文本,现在和解密的纯文本,他们能确定用于加密信息的密钥吗?
根据所使用的加密算法,纯文本和密文的知识不会显示密钥。否则,一个已知明文块(例如,公共头或攻击者控制的值)将破坏密码!这样的密钥恢复攻击对于任何现代设计良好的密码来说都是非常罕见的。您使用的基于支持多个安全密码的DJB的Salsa20 20算法库。所有使用的密码都是安全的,免受密钥恢复攻击。
为了简单起见,对软件中的其他加密功能使用相同的密钥是有用的。
重复使用钥匙用于任何其他目的通常是一个非常糟糕的主意。每次不同的加密使用都应该使用一个新密钥。例如,CSRF令牌加密密钥不应与链接加密密钥相同。如果确实有一个键大小的值,则可以将其安全地展开为多个键。一种安全的方法是使用流行的香港发展基金函数。您可以为函数提供一个主密钥,它将显示出任意数量的适合使用的加密安全密钥。
发布于 2018-07-02 12:12:25
森林肯定回答了一些问题,但我也想添加一个类似的部分:
为什么要为CSRF令牌重用用户的登录令牌?
虽然重用用户登录CSRF并没有上升到“安全错误”的水平,但我也不会考虑它的最佳实践,并将避免它,除非有一个很好的理由。像您正在做的那样重用它并不会立即创建安全漏洞,但通常情况下,重用密钥/令牌是您在路上无意中引入安全问题的原因。通常情况下,这种情况最终会发生,因为有人在系统的某一部分上做了更改,却没有意识到它在其他地方的含义。
但是,这确实会造成一个安全缺陷,即在每个请求之后都不能重新生成CSRF令牌。每次使用后重新生成CSRF令牌是推荐的(虽然不是必要的)安全步骤,它还可以帮助防止意外的双重提交。因此,我建议仅仅实现一个单独的CSRF令牌,如果这样做对您的系统不是一个大麻烦。毕竟,为什么要为登录令牌的加密/nonce/etc而费事来创建一个CSRF呢?CSRF令牌所需要的是唯一和不可预测的。生成一个长(密码安全的)随机字符串并将其存储在cookie中以供您的CSRF令牌使用也同样容易。无需登录令牌重用。
https://security.stackexchange.com/questions/188738
复制相似问题