php会话id有多独特

How unique is the php session id? I got the impression from various things that I've read that I should not rely on two users never getting the same sessionid. Isn't it a GUID?

php会话id有多独特?我从我读过的很多东西中得到了这样的印象，我不应该依赖两个用户永远得不到相同的sessionid。这不是一个GUID吗?

7 个解决方案

#1

Session_id can indeed be duplicated, but the probability is very low. If you have a website with a fair traffic, it may happens once in you web site life, and will just annoy one user for one session.

Session_id确实可以复制，但是概率非常低。如果你有一个网站有一个公平的流量，它可能发生一次在你的网站生活，并将仅仅骚扰一个用户为一个会话。

This is not worth to care about unless you expect to build a very high traffic website or a service for the bank industry.

除非你想建立一个高流量的网站，或者为银行行业提供服务，否则这是不值得关注的。

#2

It's not very unique as shipped. In the default configuration it's the result of a hash of various things including the result of gettimeofday (which isn't terribly unique), but if you're worried, you should configure it to draw some entropy from /dev/urandom, like so

它并不是唯一的。在默认配置中，它是各种事情的散列结果，包括gettimeofday的结果(它并不是非常独特)，但是如果您担心这个问题，您应该将它配置为从/dev/urandom中绘制一些熵，就像这样

ini_set("session.entropy_file", "/dev/urandom");
ini_set("session.entropy_length", "512");

search for "php_session_create_id" in the code for the actual algorithm they're using.

在他们使用的实际算法的代码中搜索“php_session_create_id”。

Edited to add: There's a DFA random-number generator seeded by the pid, mixed with the time in usecs. It's not a firm uniqueness condition especially from a security perspective. Use the entropy config above.

编辑为添加:有一个DFA随机数生成器由pid播种，与usecs中的时间混合。它不是一个严格的唯一性条件，尤其是从安全的角度来看。使用上面的熵配置。

Update:

更新:

As of PHP 5.4.0 session.entropy_file defaults to /dev/urandom or /dev/arandom if it is available. In PHP 5.3.0 this directive is left empty by default. PHP Manual

从PHP 5.4.0会话开始。如果有的话，entropy_file默认为/dev/urandom或/dev/arandom。在PHP 5.3.0中，该指令默认为空。PHP手册

#3

You can install an alternative hash generation function if you want to customise the way the ID is generated (it's a 128bit number generated via MD5 by default). See http://www.php.net/manual/en/session.configuration.php#ini.session.hash-function

如果您想定制生成ID的方式(它是默认通过MD5生成的128位数字)，您可以安装另一个哈希生成函数。看到http://www.php.net/manual/en/session.configuration.php ini.session.hash-function

For more information on PHP sessions, try this excellent article http://shiflett.org/articles/the-truth-about-sessions which also links to other articles about session fixation and hijack.

有关PHP会话的更多信息，请尝试本文http://shiflett.org/articles/the truth- aboutsessions，该文章也链接到其他有关会话固定和劫持的文章。

#4

If you want to know how PHP generates a session ID by default check out the source code on Github. It is certainly not random and is based on a hash (default: md5) of these ingredients (see line 310 of code snippet):

如果您想知道PHP如何在默认情况下生成会话ID，请查看Github上的源代码。它当然不是随机的，而是基于这些成分的散列(默认值:md5)(参见代码片段的第310行):

IP address of the client
客户端的IP地址
Current time
当前时间
PHP Linear Congruence Generator - a pseudo random number generator (PRNG)
一个伪随机数发生器(PRNG)
OS-specific random source - if the OS has a random source available (e.g. /dev/urandom)
特定于操作系统的随机源——如果操作系统有可用的随机源(例如/dev/urandom)

If the OS has a random source available then strength of the generated ID for the purpose of being a session ID is high (/dev/urandom and other OS random sources are (usually) cryptographically secure PRNGs). If however it does not then it is satisfactory.

如果操作系统有一个可用的随机源，那么为作为会话ID而生成的ID的强度很高(/dev/urandom和其他操作系统随机源(通常)是加密安全的PRNGs)。然而，如果它没有，那么它是令人满意的。

The goal with session identification generation is to:

会话识别生成的目标是:

minimise the probability of generating two session IDs with the same value
最小化生成两个具有相同值的会话id的可能性
make it very challenging computationally to generate random keys and hit an in use one.
在计算上非常具有挑战性，生成随机键并点击一个in use键。

This is achieved by PHP's approach to session generation.

这是通过PHP的会话生成方法实现的。

You cannot absolutely guarantee uniqueness, but the probabilities are so low of hitting the same hash twice that it is, generally speaking, not worth worrying about.

你不能绝对保证唯一性，但概率是如此之低，以至于一般来说，它是不值得担心的。

#5

Size of session_id
Assume that seesion_id is uniformly distributed and has size=128 bits. Assume that every person on the planet logs in once a day with a persistent an new session for 1000 years.

session_id的大小假设seesion_id是均匀分布的，大小为128位。假设地球上的每个人每天登录一次，并持续一个新的会话，持续1000年。

num_sesion_ids  = 1000*365.25 *7*10**9 < 2**36
collission_prob < 1 - (1-1/2**82)**(2**36)  ≈ 1 - e**-(1/2**46) 
                ≈ 1/2**46

So the the probability of one or more collision is less than one in 70 thousand billions. Hence the a 128-bit-size of the session_id should be big enough. As mentioned in other comments, the session_manager might also check that new session_id does not already exist.

所以一个或多个碰撞的概率小于7万亿分之一。因此，session_id的128位大小应该足够大。正如在其他注释中提到的，session_manager也可能检查新的session_id是否已经存在。

Randomness
Therefore the big question I think is whether the session_id:s are generated with good pseudo randomness. On that you can never be sure, but I would recommend using a well known, and frequently used standard solution for this purpose (as you probably already do).

因此，我认为最大的问题是session_id:s是否具有良好的伪随机性。在这一点上，您永远无法确定，但我建议您为此使用一个众所周知的、经常使用的标准解决方案(您可能已经这样做了)。

Even if collisions are avoided due to checking, randomness and size of session_id is important, so that hackers can not, somehow do qualified guessing and find active session_id:s with large probability.

即使由于检查避免了冲突，session_id的随机性和大小也很重要，因此黑客无法以某种方式进行限定猜测并找到具有较大概率的活动session_id:s。

#6

I have not found a confirmation on this but i believe php checks if a session id already exists before creating one with that id.

我还没有找到关于这个的确认，但是我相信php会检查一个会话id是否已经存在，然后再创建一个id。

The session hijacking issue people are worried about is when someone finds out the session id of an active user. This can be prevented in many ways, for more info on that you can see this page on php.net and this paper on session fixation

人们担心的会话劫持问题是当有人发现活动用户的会话id时。这可以在很多方面得到预防，更多的信息可以在php.net上看到，这篇关于会话固定的文章

#7

No, session id is not a GUID, but two users should not get the same session id as they are stored on the server side.

不，会话id不是GUID，但是两个用户不应该获得与存储在服务器端相同的会话id。

#1