Rails cookie会话存储的工作方式如下:
1.它将会话数据序列化为字节字符串。 2.序列化数据被转换为base64。 3.base64数据被附加一个HMAC。Rails要求HMAC密钥至少为30个字节;默认情况下,Rails从/dev/urandom获取128个字节的随机字符串作为密钥。用于HMAC的默认哈希算法是SHA-1。 4.base64数据+HMAC作为cookie发送到HTTP客户端。 5.当客户端执行请求时,Rails首先检查HMAC验证是否成功。如果不成功,则会静默丢弃cookie中的会话数据,就好像用户根本没有发送任何会话数据一样。这也意味着,如果管理员更改了HMAC密钥,则所有旧会话都会自动失效。 6.base64数据被解码并取消序列化为Ruby数据结构。
我正在编写的加密cookie会话存储子类化了正常的cookie存储类。它的工作方式如下:
1.在第3步之后插入一个3.5步骤:它将加密数据。 2.修改第5步:在检查HMAC之前,它将解密数据。 3.加密算法是CFB模式下的AES-256。我知道EBC会暴露重复的模式。 4.该代码要求管理员指定一个长度为32字节的加密密钥。加密密钥没有被哈希。默认情况下,它建议从/dev/urandom获得一个随机生成的32字节加密密钥。 5.它还要求管理员指定一个长度为16字节的初始化向量。IV没有被哈希,而且默认情况下,它建议从/dev/urandom获得一个随机生成的IV。
我在加密之前进行HMAC(而不是加密后进行HMAC)的原因是因为我想能够检测到加密密钥或IV的更改。如果加密后进行HMAC,则如果我更改加密密钥或IV,则HMAC验证将通过,这是不可取的。
我的方法安全吗?如果不是,那么缺少什么?
一些注释:
- 我想采用CTR模式,正如http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html所推荐的那样。但不幸的是,OpenSSL(包含在Ruby标准库中)不支持CTR模式,而我不想要求用户安装单独的第三方加密库。
- 我想使用SHA-256作为HMAC算法。daemonology.net建议避免使用SHA-512,因为可能存在“32位系统的侧信道攻击”(不管这是什么意思)。然而,并非所有平台都支持HMAC+SHA256算法。尤其是,在OS X上安装的Ruby不支持HMAC+SHA256。我希望我的代码可以在OS X上开箱即用。