会话哈希大小重要吗？
在选择用于会话哈希的正确算法时，大小是否重要？
我最近读了这个 文章 它建议使用 Whirlpool 为会话 ID 创建哈希。 Whirlpool 生成 128 个字符的哈希字符串，这是否太大？
计划是将会话哈希存储在数据库中。使用 64 个字符字段 (sha256)、96 个字符字段 (sha384) 或 128 个字符字段 (whirlpool) 之间有很大区别吗？ Whirlpool 最初的争论之一是速度与其他算法的比较，但看看 sha384 的速度结果并不算太糟糕。
可以选择截断哈希值，使其小于 128 个字符。
我确实修改了原始代码片段，以允许根据需要更改算法。
更新：有一些关于字符串被散列的讨论，所以我包含了代码。
function generateUniqueId($maxLength = null) {
$entropy = '';
// try ssl first
if (function_exists('openssl_random_pseudo_bytes')) {
$entropy = openssl_random_pseudo_bytes(64, $strong);
// skip ssl since it wasn't using the strong algo
if($strong !== true) {
$entropy = '';
}
}
// add some basic mt_rand/uniqid combo
$entropy .= uniqid(mt_rand(), true);
// try to read from the windows RNG
if (class_exists('COM')) {
try {
$com = new COM('CAPICOM.Utilities.1');
$entropy .= base64_decode($com->GetRandom(64, 0));
} catch (Exception $ex) {
}
}
// try to read from the unix RNG
if (is_readable('/dev/urandom')) {
$h = fopen('/dev/urandom', 'rb');
$entropy .= fread($h, 64);
fclose($h);
}
// create hash
$hash = hash('whirlpool', $entropy);
// truncate hash if max length imposed
if ($maxLength) {
return substr($hash, 0, $maxLength);
}
return $hash;
}
Does size matter when choosing the right algorithm to use for a session hash.
I recently read this article and it suggested using whirlpool to create a hash for session id. Whirlpool generates a 128 character hash string, is this too large?
The plan is to store the session hash in a db. Is there much of a difference between maybe using 64 character field (sha256), 96 character field (sha384) or 128 character field (whirlpool)? One of the initial arguments made for whirlpool was the speed vs other algorithms but looking at the speed results sha384 doesn't fair too badly.
There is the option truncate the hash to make it smaller than 128 characters.
I did modify the original code snippet, to allow changing of the algorithm based of the needs.
Update: There was some discussion about string being hashed, so I've included the code.
function generateUniqueId($maxLength = null) {
$entropy = '';
// try ssl first
if (function_exists('openssl_random_pseudo_bytes')) {
$entropy = openssl_random_pseudo_bytes(64, $strong);
// skip ssl since it wasn't using the strong algo
if($strong !== true) {
$entropy = '';
}
}
// add some basic mt_rand/uniqid combo
$entropy .= uniqid(mt_rand(), true);
// try to read from the windows RNG
if (class_exists('COM')) {
try {
$com = new COM('CAPICOM.Utilities.1');
$entropy .= base64_decode($com->GetRandom(64, 0));
} catch (Exception $ex) {
}
}
// try to read from the unix RNG
if (is_readable('/dev/urandom')) {
$h = fopen('/dev/urandom', 'rb');
$entropy .= fread($h, 64);
fclose($h);
}
// create hash
$hash = hash('whirlpool', $entropy);
// truncate hash if max length imposed
if ($maxLength) {
return substr($hash, 0, $maxLength);
}
return $hash;
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
创建哈希所花费的时间并不重要，只要数据库正确索引，存储方法也不应该成为主要因素。
然而，哈希值每次都必须与客户端的请求一起传输，通常作为 cookie。大型 cookie 可能会为每个请求增加少量的额外时间。有关详细信息，请参阅Yahoo! 的页面性能最佳实践。较小的 cookie 以及较小的哈希值是有好处的。
总体而言，大型哈希函数可能不合理。由于其范围有限，旧的 md5 和 sha1 可能足以作为会话令牌背后的源。
The time taken to create the hash is not important, and as long as your database is properly indexed, the storage method should not be a major factor either.
However, the hash has to be transmitted with the client's request every time, frequently as a cookie. Large cookies can add a small amount of additional time to each request. See Yahoo!'s page performance best practices for more information. Smaller cookies, thus a smaller hash, have benefits.
Overall, large hash functions are probably not justified. For their limited scope, good old md5 and sha1 are probably just fine as the source behind a session token.
是的，尺寸很重要。
如果太短，就有发生碰撞的风险。您还可以让攻击者通过暴力攻击找到其他人的会话。
太长并不重要，但会话 ID 的每个字节都必须在每次请求时从浏览器传输到服务器，因此如果您确实正在优化某些内容，您可能不希望 ID 太长。
不过，您不必使用哈希算法的所有位 - 没有什么可以阻止您使用像 Whirlpool 这样的算法，然后只采用前 128 位（十六进制的 32 个字符）。实际上，128 位也是一个不错的长度下限。
不过，正如埃里克森指出的那样，使用哈希有点奇怪。除非您的输入熵至少与您所使用的 ID 的长度一样多，否则您很容易受到猜测哈希输入的攻击。
Yes, size matters.
If it's too short, you run the risk of collisions. You also make it practical for an attacker to find someone else's session by brute-force attack.
Being too long matters less, but every byte of the session ID has to be transferred from the browser to the server with every request, so if you're really optimising things, you may not want an ID that's too long.
You don't have to use all the bits of a hash algorithm, though - there's nothing stopping you from using something like Whirlpool, then only taking the first 128 bits (32 characters in hex). Practically speaking, 128 bits is a good lower bound on length, too.
As erickson points out, though, using a hash is a bit odd. Unless you have at least as much entropy as input as the length of the ID you're using, you're vulnerable to attacks that guess the input to your hash.
当我尝试阅读该文章时，它超时了，但我想不出使用哈希作为会话标识符的好理由。会话标识符应该是不可预测的；鉴于文章的标题，听起来作者承认了这一原则。那么，为什么不使用加密随机数生成器来生成会话标识符呢？
哈希接受输入，如果该输入是可预测的，那么哈希也是可预测的，这很糟糕。
The article times out when I try to read it, but I can't think of a good reason to use a hash as a session identifier. Session identifiers should be unpredictable; given the title of the article, it sounds like the authors acknowledge that principle. Then, why not use a cryptographic random number generator to produce session identifiers?
A hash takes input, and if that input is predictable, so is the hash, and that's bad.
SHA1 或 MD5 可能足以满足您的需求。实际上，发生碰撞的概率非常小，很可能永远不会发生。
但最终，这一切都取决于您所需的安全级别。还要记住，较长的哈希值的计算成本更高，并且需要更多的存储空间。
SHA1 or MD5 is probably enough for your needs. In practice, the probability of a collision is so small that it will likely never happen.
Ultimately, though, it all depends upon your required level of security. Do also keep in mind that longer hashes are both more expensive to compute and require more storage space.