Request #65501 uniqid(): More entropy parameter should be true by default

11 years ago by Nikita Popov — view source

unread

Hi all,

I realized that not many users are using "more entropy" parameter
Therefore, I made

Request #65501 uniqid(): More entropy parameter should be true by default
https://bugs.php.net/bug.php?id=65501

The comment title explains what this FR is.

Any comments?

I don't really have an opinion on this, but one comment:

With more_entropy=false the uniqid() function is horribly slow on unix
system (because it does a usleep). Setting more_entropy=true usually makes
the call a few orders of magnitude faster. So that might be another
advantage to enable by default ;)

Nikita

11 years ago by Tjerk Meesters — view source

unread

Hi,

Hi all,

I realized that not many users are using "more entropy" parameter
Therefore, I made

Request #65501 uniqid(): More entropy parameter should be true by default
https://bugs.php.net/bug.php?id=65501

The comment title explains what this FR is.

Any comments?

I would like to mention that the return value would become 10 characters longer if we enable this by default. This could break applications that store the value in a database column such as VARCHAR(20).

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Andreas Heigl — view source

unread

Hi,

Am 22.08.13 14:10, schrieb Tjerk Meesters:

Hi,

Hi all,

I realized that not many users are using "more entropy" parameter
Therefore, I made

Request #65501 uniqid(): More entropy parameter should be true by default
https://bugs.php.net/bug.php?id=65501

The comment title explains what this FR is.

Any comments?

I would like to mention that the return value would become 10 characters longer if we enable this by default. This could break applications that store the value in a database column such as VARCHAR(20).

Would it be possible to add a parameter to php.ini whether or not to set
moreentropy to true? Which by default of course is 'true'? So for most
installations it would be enabled and if it breaks there is one space to
reset to the previous behaviour.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Regards

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

11 years ago by Marco Pivetta — view source

unread

Hi,

Would it be possible to add a parameter to php.ini whether or not to set
moreentropy to true? Which by default of course is 'true'? So for most
installations it would be enabled and if it breaks there is one space to
reset to the previous behaviour.

Hi Andreas,

PHP moved away from the "ini-setting-for-all-the-things" approach, since it
causes more entropy than what it attempts to fix.

Marco Pivetta

11 years ago by Adam Harvey — view source

unread

I realized that not many users are using "more entropy" parameter
Therefore, I made

Request #65501 uniqid(): More entropy parameter should be true by default
https://bugs.php.net/bug.php?id=65501

I would like to mention that the return value would become 10 characters longer if we enable this by default. This could break applications that store the value in a database column such as VARCHAR(20).

This is 6.x material to me for exactly that reason — we have changed
the defaults for functions with optional behaviour before, but I think
this one has more scope to break applications due to the potential for
data loss when users have used limited database columns (and I suspect
a lot of uniqid() users are storing the result in a database).

Since there is a need for "unique" values, would we be better off
considering bundling the uuid extension (or something similar) to
provide a simple way of generating UUIDs? No BC considerations then,
and it's probably a better option for unique identifier generation
regardless.

Adam

11 years ago by Sebastian Krebs — view source

unread

2013/8/22 Yasuo Ohgaki yohgaki@ohgaki.net

Hi all,

I realized that not many users are using "more entropy" parameter
Therefore, I made

Request #65501 uniqid(): More entropy parameter should be true by default
https://bugs.php.net/bug.php?id=65501

The comment title explains what this FR is.

Any comments?

Tbh I don't get the real problem with the current behaviour. Who need the
entropy, can set it as second parameter and I am not sure, if it is wise to
use uniqid() for security purposes.

Regards
Sebastian

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
github.com/KingCrunch

11 years ago by Leigh — view source

unread

Tbh I don't get the real problem with the current behaviour. Who need the
entropy, can set it as second parameter and I am not sure, if it is wise to
use uniqid() for security purposes.

It's absolutely not wise to use it for anything security related, the
purpose of the function is simply to provide a unique value within a
system, not a random value, not an unpredictable value.

"more_entropy" in this case might as well be called "higher_resolution". As
Nikita already pointed out, without this flag set a usleep is performed to
force function calls to be at least 1 microsecond apart (since the id is
microtime based). All more_entropy does is add some additional random on
the end instead of the usleep so when uniqid is called multiple times
during the same microsecond, the values are still (probably) unique.

Making the function return a longer output by default is a BC break imo. As
already pointed out constrained DB fields will not accept the new default,
filenames generated using it will no longer conform to a set pattern, etc.
etc.

11 years ago by Sebastian Krebs — view source

unread

2013/8/22 Leigh leight@gmail.com

Tbh I don't get the real problem with the current behaviour. Who need
the
entropy, can set it as second parameter and I am not sure, if it is wise
to
use uniqid() for security purposes.

It's absolutely not wise to use it for anything security related, the
purpose of the function is simply to provide a unique value within a
system, not a random value, not an unpredictable value.

Thats what was my thought too, but the bugreport states

Without more entropy, uniqid() may produce non unique id even if the
name states
it. This could be security issue under certain cases.

"more_entropy" in this case might as well be called "higher_resolution".
As Nikita already pointed out, without this flag set a usleep is performed
to force function calls to be at least 1 microsecond apart (since the id is
microtime based). All more_entropy does is add some additional random on
the end instead of the usleep so when uniqid is called multiple times
during the same microsecond, the values are still (probably) unique.

Wait ... With "more" it is faster?! (Havent read Nikitas mail so closely
before...). Definitely something I should remember ^^ My trivial mind would
assume, that the longer output would take more effort.

Making the function return a longer output by default is a BC break imo.
As already pointed out constrained DB fields will not accept the new
default, filenames generated using it will no longer conform to a set
pattern, etc. etc.

Worth to mention: The longer output also contains a dot ".", which may lead
to worse things with filenames ;)

Regards,
Sebastian

--
github.com/KingCrunch

11 years ago by Yasuo Ohgaki — view source

unread

Tbh I don't get the real problem with the current behaviour. Who need
the
entropy, can set it as second parameter and I am not sure, if it is wise
to
use uniqid() for security purposes.

It's absolutely not wise to use it for anything security related, the
purpose of the function is simply to provide a unique value within a
system, not a random value, not an unpredictable value.

I agree.

However, I suppose there are many applications that rely on uniqid() for
critical features like payment or authentication.

We need better function as basic feature of PHP. unique_hash() or
hash_unique() might be good. UUID works and is much better but generating
unique hash just like session ID is trivial to implement.

Any comments on this?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Yasuo Ohgaki — view source

unread

We need better function as basic feature of PHP. unique_hash() or
hash_unique() might be good. UUID works and is much better but generating
unique hash just like session ID is trivial to implement.

Any one working on UUID module?
Fedora uses OSSP's UUID lib. I would like to create UUID module if no one
is working on it. It relies on external lib, so I think we need something
like hash_unique() regardless of UUID module.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by David Muir — view source

unread

We need better function as basic feature of PHP. unique_hash() or
hash_unique() might be good. UUID works and is much better but generating
unique hash just like session ID is trivial to implement.

Any one working on UUID module?
Fedora uses OSSP's UUID lib. I would like to create UUID module if no one
is working on it. It relies on external lib, so I think we need something
like hash_unique() regardless of UUID module.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Well, there's this:

http://pecl.php.net/package/uuid

David

11 years ago by Yasuo Ohgaki — view source

unread

Hi David,

Well, there's this:

http://pecl.php.net/package/uuid

I meant UUID module for source distribution. Sorry, I should have mentioned
this.

PECL's UUID module is LGPL, so the license is needed to be changed.
It uses ext2util lib. I suppose it would be Linux only module.

OSSP seems to have PHP module and it's MIT. We may copy it.
Any issue copying it? This would be the easiest.

Or we can write PHP licensed module from scratch. It's a simple wrapper.
People in this list can write it easily.

The last option is most preferred, IMO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Lars Strojny — view source

unread

Hi everyone,

adding UUID functionality to the core would be very cool. Especially in times where we create more and more primary keys in the code, not in the database.

cu,
Lars

Am 23.08.2013 um 23:53 schrieb Yasuo Ohgaki yohgaki@ohgaki.net:

Hi David,

Well, there's this:

http://pecl.php.net/package/uuid

I meant UUID module for source distribution. Sorry, I should have mentioned
this.

PECL's UUID module is LGPL, so the license is needed to be changed.
It uses ext2util lib. I suppose it would be Linux only module.

OSSP seems to have PHP module and it's MIT. We may copy it.
Any issue copying it? This would be the easiest.

Or we can write PHP licensed module from scratch. It's a simple wrapper.
People in this list can write it easily.

The last option is most preferred, IMO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Nikita Popov — view source

unread

Hi everyone,

adding UUID functionality to the core would be very cool. Especially in
times where we create more and more primary keys in the code, not in the
database.

cu,
Lars

We already have a great (version 4) UUID implementation called
mcrypt_create_iv, just minus the fixed sequences and fancy formatting.
Apart from moving this to core (not requiring mcrypt/openssl) and maybe
adding alphabet support, I don't immediately see why this wouldn't be
sufficient. Why do we need fancy UUID formatting or "unique hashes"
(whatever that is supposed to be...)?

Nikita

11 years ago by Lars Strojny — view source

unread

Hi Nikita,

Am 24.08.2013 um 12:08 schrieb Nikita Popov nikita.ppv@gmail.com:
[....]

We already have a great (version 4) UUID implementation called
mcrypt_create_iv, just minus the fixed sequences and fancy formatting.
Apart from moving this to core (not requiring mcrypt/openssl) and maybe
adding alphabet support, I don't immediately see why this wouldn't be
sufficient. Why do we need fancy UUID formatting or "unique hashes"
(whatever that is supposed to be...)?

mcrypt_create_iv() is great but it is about usability: not every user of the language can create a UUIDs from mcrypt_create_iv() and we should make it as easy as possible to generate unique IDs. That said, a simple uuid($version) function would not hurt the core. I would argue that this is very similar to the password_hash() API. It was possible before the password API to store password securely, but we made it way easier now, which is a very good thing.

cu,
Lars

11 years ago by Anthony Ferrara — view source

unread

Yasuo,

It's absolutely not wise to use it for anything security related, the

purpose of the function is simply to provide a unique value within a
system, not a random value, not an unpredictable value.

I agree.

However, I suppose there are many applications that rely on uniqid() for
critical features like payment or authentication.

Sure, and people use eval() for conditionals and goto for code
structure.

We shouldn't alter language design for people making bad decisions.
Instead, we should work on documentation and education to fix those kinds
of problems.

We need better function as basic feature of PHP. unique_hash() or
hash_unique() might be good. UUID works and is much better but generating
unique hash just like session ID is trivial to implement.

What would this do? How would it work? Would it just be a statistically
unique hash? At which point why have it named on hash instead of just
being a large random number (and hence belongs as a random number
generator, not a unique hash thingy)...

My $0.02.

Anthony

11 years ago by Yasuo Ohgaki — view source

unread

Hi Anthony,

On Fri, Aug 23, 2013 at 11:12 PM, Anthony Ferrara ircmaxell@gmail.comwrote:

It's absolutely not wise to use it for anything security related, the

purpose of the function is simply to provide a unique value within a
system, not a random value, not an unpredictable value.

I agree.

However, I suppose there are many applications that rely on uniqid() for
critical features like payment or authentication.

Sure, and people use eval() for conditionals and goto for code
structure.

We shouldn't alter language design for people making bad decisions.
Instead, we should work on documentation and education to fix those kinds
of problems.

We definitely should do this. I agree.

We need better function as basic feature of PHP. unique_hash() or
hash_unique() might be good. UUID works and is much better but generating
unique hash just like session ID is trivial to implement.

What would this do? How would it work? Would it just be a statistically
unique hash? At which point why have it named on hash instead of just
being a large random number (and hence belongs as a random number
generator, not a unique hash thingy)...

Right. It would be statistically unique hash just like session ID without
strict session mode.
(Strict session detects collision, so it ensures uniqueness)

Current session module uses /dev/urandom (or like in UNIX like environment)
or crypt library
for windows. We have been relied statistically unique session ID until now,
since it's not too bad.

hash_unique() would be much safer than uniqid(). We should still educate
users that values are
statistically unique values. Unlike session, collision detection is up to
users since it's impossible
to maintain generated hash values.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Yasuo Ohgaki — view source

unread

We shouldn't alter language design for people making bad decisions.

Instead, we should work on documentation and education to fix those kinds
of problems.

We definitely should do this. I agree.

I agree with part of documentation and education :)
uniqid() is not adequate for payment nor authentication.

It is preferred that adopting secure defaults for new release.
People do mistakes and don't read documentation. Better security
by default is the way to go. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net