Xeo*_*oss 5 encryption cookies cryptography rijndael
我正在考虑切换到将会话数据存储在加密的cookie中,而不是存储在我的服务器上.虽然这将为每个请求带来更多带宽 - 但它将节省额外的数据库服务器负载和存储空间.
无论如何,我计划使用RIJNDAEL 256 加密cookie内容.
function encrypt($text, $key)
{
return mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key,$text,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,MCRYPT_MODE_ECB),MCRYPT_RAND));
}
Run Code Online (Sandbox Code Playgroud)
哪个在使用会产生这样的东西(base64编码显示)
print base64_encode(encrypt('text', 'key'));
7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw=
Run Code Online (Sandbox Code Playgroud)
我并不担心一个用户的cookie被破坏不亚于我担心攻击者发现key,并能够建立任何会话的任何用户,因为他们知道我使用对数据进行签名.
有没有办法可以验证与所用参数相关的估计开裂时间?或者是否有与所用文本或密钥大小相关的标准时间度量?
我听到有人说,超过所需的256位密钥自己是足够安全与RIJNDAEL算法使用.我也想知道加密文本的长度是否需要一定的长度,以免泄露密钥.
数据通常约为200个字符
a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";}
Run Code Online (Sandbox Code Playgroud)
这样安全吗?
roo*_*ook 15
是的Rijndael(AES)是安全的,但您的实施远非安全.您的实施有两个悬而未决的问题.使用ECB模式和IV是一个静态变量,将用于所有消息. IV必须始终是加密Nonce.您的代码明显违反了CWE-329.
永远不要使用ECB模式,必须使用CBC模式,这就是为什么:
原版的:

使用ECB模式加密:

使用CBC模式加密:

避免使用欧洲央行。它可以揭示有关加密内容的信息。任意两个具有相同明文的块将具有相同的密文。CBC 可以避免这种情况,但需要生成或保存 IV。
避免简单地保存密钥和 IV。使用加密的强随机数生成器生成 256 位主密钥,并将其保存到您的应用程序中安全的地方。使用它来生成用于加密的会话密钥。IV 可以从会话密钥中导出。生成会话密钥时,请包括可用于缩小会话密钥范围的所有可用数据。(例如,包括 cookie 的范围、远程主机地址、与加密数据一起存储的随机提示和/或用户 ID(如果不在加密数据内)
根据数据的使用方式,您可能必须包含 MAC。ECB 和 CBC 的设计目的不是检测密文的任何更改,此类更改将导致明文产生垃圾。您可能希望在加密数据中包含 HMAC,以便您在将其视为规范之前对其进行身份验证。会话 HMAC 密钥必须从会话加密密钥派生。或者,您可以使用 PCBC 模式。PCBC 旨在检测密文中的变化,但其检测能力受到填充大小的限制,这取决于加密的数据,并且并非所有加密 API 都会将其作为选项。
一旦您已经包含了 MAC,那么您应该考虑采取措施来防止重放攻击。任何时候有人可以在会话范围内重新发送旧数据,就有可能遭受重放攻击。阻止重放攻击的一种方法是在不给用户造成问题的情况下尽可能缩小会话密钥的使用范围。您可以做的另一件事是在加密数据中包含日期和时间,以在数据被视为有效时创建一个窗口。
在夏季,保护钥匙只是冰山一角。
| 归档时间: |
|
| 查看次数: |
3078 次 |
| 最近记录: |