25
4
As the title asks,
正如书名所说，
What are the pros and cons of high php session.sid_bits_per_character and session.sid_length?
The obvious pros are that the higher bits and length means even harder to brute force or overlaps, but is there much or any cons aside from the vague compatibility problem?
高php会话数.sid_bitsper_Character和会话数.sid_long的优缺点是什么？显而易见的好处是，更高的比特和长度意味着更难暴力或重叠，但除了模糊的兼容性问题，还有很多或任何不利之处吗？
I ask this as that is as much information the manual provides.
https://www.php.net/manual/en/session.configuration.php#ini.session.hash-function
我问这个是因为这是手册提供的所有信息。Https://www.php.net/manual/en/session.configuration.php#ini.session.hash-function
I can imagine possible cons, but these are at most dumb guesses.
我可以想象可能的骗局，但这些充其量都是愚蠢的猜测。
Is there any reason NOT to change these 2 settings to the following in the php.ini file?
有什么理由不在php.ini文件中将这两个设置更改为以下设置吗？
个人中心
文章发布
退出sid_bits_per_character = 6
sid_length = 256
edit: added the possible con of using more resources
编辑：添加了使用更多资源的可能缺点
As always: it depends. The longer, and the more characters, the more secure. I don't think you will notice any speed impact. Also as cookies are always transmitted in the headers, that little more size won't really matter. If it IS about speed, you need to benchmark for YOUR system. You also can use memcached or redis as alternative storing the SID instead of the file system storage.
一如既往：这要视情况而定。长度越长，字符越多，就越安全。我认为你不会注意到任何速度影响。此外，由于Cookie总是在报头中传输，所以稍微多一点大小并不重要。如果是关于速度，您需要针对您的系统进行基准测试。您还可以使用Memcached或redis作为替代存储SID的方法，而不是文件系统存储。
@MarkusZeller Thanks for the comment. I don't have anything resembling a system yet, just a rdbms and xampp. Am I correct in assuming that using file system storage is the slowest for sid matching, rdbms key column next, and memcached/redis the fastest as they are straight key/val referencing? Or is memcached/redis pretty much equivalent with rdbms (mysql) table with a primary key column? But in general I am getting from you is that it doesn't matter and longer+more bits is better.
@MarkusZeller感谢您的评论。我还没有任何类似系统的东西，只有RDBMS和XAMPP。我假设使用文件系统存储是sid匹配最慢的，其次是RDBMS键列，而memcached/red是最快的，因为它们是直接的键/val引用，这样的假设正确吗？还是Memcached/redis几乎等同于具有主键列的RDBMS(MySQL)表？但总的来说，我从你那里得到的是，这并不重要，越长+越多越好。
Also here it depends. A *NIX filesystem is phreaking fast and can be even faster than a in memory cache (because of handling connections). I would use one if you need to share a key/value store over multiple server instances and only change to optimize anything when you encounter any performance bottlenecks. As said, you need to measure for YOUR system.
这里也要视情况而定。*NIX文件系统速度很快，甚至可以比内存缓存更快(因为要处理连接)。如果您需要在多个服务器实例上共享一个键/值存储，并且只有在遇到任何性能瓶颈时才进行更改以优化任何内容，我会使用一个。如上所述，您需要为您的系统进行测量。
@MarkusZeller Let me state some other conditions a) The only system I have is my PC and b) I'm currently using a RDBMS for the session storage and c) I am using phpsession. Other types of storages are better/worse of course. But the question is NOT for my MY system, but for in general if there is any meaningful impact to speed/load/performance with higher SID length and bit size.
@MarkusZeller让我说明一些其他条件a)我拥有的唯一系统是我的PC，b)我当前使用的是RDBMS用于会话存储，c)我使用的是phpession。当然，其他类型的存储设备更好/更差。但问题不在于我的系统，而在于一般来说，较高的SID长度和位大小是否会对速度/负载/性能产生任何有意义的影响。
@MarkusZeller Thank you, I'll investigate "the right indexes" and "in memory tables" things. They seem interesting especially the in memory table for mySQL, as the answer says that since sids are ephemeral, losing a session table on reboot seems ok.
@MarkusZeller谢谢，我会调查“正确的索引”和“在内存表中”的事情。它们似乎很有趣，尤其是MySQL的内存表，因为答案是说，由于SID是短暂的，在重新引导时丢失会话表似乎是可以的。
sids are ephemeral rather than permanent. So the number of them you need to store is proportional to the number of active users you have, not total users. That's good when you use an RDBMS for session storage: in large tables random primary keys are not very efficient but session tables -- with sids for primary keys -- aren't that large.
小岛屿发展中国家是短暂的，而不是永久的。因此，您需要存储的用户数量与您拥有的活动用户数量成正比，而不是与总用户数量成正比。当您使用RDBMS进行会话存储时，这很好：在大型表中，随机主键效率不是很高，但是会话表--主键为SID--并不是那么大。
Ephemerality also means you can change sid format in the future, with the only operational cost being the cancellation of all active sessions when you switch. You can get away with that once in a great while if you announce scheduled downtime.
短暂性还意味着您可以在未来更改sid格式，唯一的运营成本是在您切换时取消所有活动会话。如果您宣布计划的停机时间，您可以在很长一段时间内幸免于难。
Longer sids are more secure. Adding six bits to a random sid makes it 64 times harder to guess. A 192-bit sid (32 bytes at six bits per byte) is just fine, and won't raise flags with people like payment-card industry infosec auditors. Longer is OK too, but 256 bytes is overkill. The extra cost, CPU, storage, and bandwidth, of a few-bytes-longer cookie value is too small to measure. You can save thousands of times more server and bandwidth resources by doing things like compressing images more efficiently. Much bigger payoff than shaving bytes off sids.
更长的SID更安全。将六位加到一个随机的sid上会使猜测的难度增加64倍。192位的sid(32字节，每字节6位)就足够了，而且不会引起支付卡行业信息安全审计人员的注意。更长也没问题，但256个字节就太过分了。更长几个字节的Cookie值的额外成本(CPU、存储和带宽)太小，无法衡量。通过更高效地压缩图像等操作，您可以节省数千倍的服务器和带宽资源。比削减小岛屿发展中国家的字节数多得多的回报。
Avoid using MD5 or SHA-1 hash algorithms. Use SHA-224 or something at least as secure. Auditors don't like the less secure ones. Using a better one saves you the hassle of explaining to the auditor how the worse ones are still ok for short-lived ephemeral values.
避免使用MD5或SHA-1散列算法。使用SHA-224或至少同样安全的东西。审计师不喜欢不太安全的公司。使用较好的方法可以省去向审计师解释为什么较差的方法仍然适用于短期价值的麻烦。
The session subsystem in php lets you switch from file-system session storage to RDBMS or cache-server storage when your site traffic grows enough that you need it : when you need multiple load-balanced web server machines. You don't have to overengineer that part of your app from day one. Just do your session-variable development correctly and you're ready for the future.
Php中的会话子系统允许您在站点流量增长到需要时从文件系统会话存储切换到RDBMS或缓存服务器存储：当您需要多台负载平衡的Web服务器计算机时。你不必从第一天起就过度设计你的应用程序的这一部分。只要正确地进行会话变量开发，就可以为未来做好准备。
So to break it down, because its ephemeral its impact to a RDBMS PK column is minimal if not negligible, but longer/random keys can be problematic if the row count gets large because it if not efficient. Otherwise, SID length/bit size performance cost is in general outside of its session storage system, IS negligible. Am I correct in this? Thank you! Also you bring up pw hash algorithms, but phpsession defaults to blowfish, I looked it up and it seems better than md5 and sha-1 at least, not sure about sha-224, is blowfish just as good or better than sha-224?
因此拆分它，因为它对RDBMS PK列的影响是短暂的，即使不是可以忽略的，也是很小的，但是如果行计数变得很大，则较长的/随机键可能会有问题，因为这样做效率不高。否则，SID长度/位大小的性能成本通常在其会话存储系统之外，可以忽略不计。这一点我说得对吗？谢谢!你也提到了PW散列算法，但phpession默认是河豚，我查了一下，它看起来至少比MD5和SHA-1要好，对SHA-224不确定，河豚是和SHA-224一样好还是更好？
Yah, blowfish is fine.
是的，河豚很好。
25
4
0
我是一名优秀的程序员,十分优秀！