[RFC] Make uniqid() more unique

Hi all,

Hm, without "true" you get 13 chars, with "true" - 20+.

Sorry. It's

$ php -r 'var_dump(uniqid(), uniqid("", true));'
string(13) "57d29c20c04c3"
string(23) "57d29c20c04c50.55225401"

I misread sprintf format.

Anyway, we may use extra 10 chars to make it more random if it should
keep compatibility. It seems uniqid() is popular for test scripts, so
it would be preferred keeping it. It does not harm any with test
script thanks to higher precision timers of current systems.

Some of us feel returning almost random value from uniqid() is
overkill. This is reasonable. I'll prepare patch that uses 10 chars
for 50 bits extra entropy from php_random_bytes() by default. It will
be a little safer even when user misuses uniqid() while keeping
most compatibility.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2016-09-09 13:18 GMT+02:00 Arvids Godjuks arvids.godjuks@gmail.com:

2016-09-09 13:37 GMT+03:00 Niklas Keller me@kelunik.com:

2016-09-09 10:36 GMT+02:00 Arvids Godjuks arvids.godjuks@gmail.com:

2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki yohgaki@ohgaki.net:

I think it's better to leave it as is and deprecate and discourage
its use.
There's already a big warning there. Dunno whether there are really
valid
use cases for it.

uniqid() is handy, when developer would like to sort something by
"time" prefix/postfix in strings. For example, prefixed/postfixed
session ID by "time".

So E_DEPRECATE might be too much.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

It's also useful in other cases, where using a full blown true random
source is just overkill.

Most people think getting true random is a overkill and implement things
non-secure.

I just don't need true random here, just some form of replacing an integer
ID with a value, that cannot be changed just by "+1"

If you know the time something was created you can still easily retrieve
it. It's not "+1" anymore, but only slightly better.

For example, my recent usage was to use the result of uniqid('', true)
as a few parameters in URL's instead of plain numeric ID. Client just
wanted to users can't do a +1 and see someone else's result page that might
have a different text or a different campaign even.

That's exactly where uniqid SHOULD NOT be used. It's predictable. Anyone
can easily guess these URLs. If you want to prevent that, you should use
non-predictable secure random, also called cryptographically secure random:
CSRPNG. See random_bytes and random_int.

The way the system works and that this is a semi-closed tool for business
purposes, the only real thing why we need these ID's is to track people.
Before this plain numeric ID's from the DB records were used. With the
rewrite the client asked to make ID's so you can't just do a +1 and see
something different. No one will ever want to try and break the uniqid algo
just to get the other page (probably the same text). I also use the
extended version of the uniqid.

uniqid() is just the current time. It's enough to be about unique in some
scenarios, but it's never unpredictable. If you want people not being able
to guess these URLs (by adding +1 or whatever), you need unpredictable
random. uniqid() doesn't fit here. uniqid("", true) doesn't fit either, as
it's just adding more time resolution and ONLY ONE SINGLE CHAR of random
data, which may be predictable, too, dunno what the generator here really
does.

And I do need to generate those id's in bursts - 200 to 600 id's in a

single action, I would imagine generating 600 random strings of ~20 char
length can be hard on the source of the randomness, may even deplete it.
And I expect the numbers to grow.

Could you outline why you need 200 - 600 IDs in a single action?

Because it's a CSV import and I need to assign every record an ID at that
moment. Those ID's are then exported by admins to a 3rd party system.

So, deprecating it I think is really an overreaction. It's a handy tool.
It can be used to generate filenames too, and a lot of other stuff.

Sure, but for that you can as well just use microtime or time. As
shown, it's easily misused, you're the perfect example. :-)

microtime and time are easier to guess. And time() is not an option,
because I will get 600 equal ID's then. Microtime is an option, but then
you get number only string and it looks awfully sequential :) Hence the
uniqid usage, that is basically time + microtime if I understand from the
manual, but it generates a bit more random result and I'm sure I get a
unique value on every call. Improving it so it does not look awfully
sequential would suffice for the use cases it is needed. In my case this
was a clearly conscious choice with full understanding how it works.

My thoughts are - improve it. Yes, the standard uniqid() is a bit too

short, I have never used it without the second "true" parameter and that
dot in the middle of the string is annoying - I had to strip it out every
use case I had.

true gives you exactly one character of more, pretty low entropy.

Regards, Niklas

Hm, without "true" you get 13 chars, with "true" - 20+.

You get more chars, it's still predictable.

Regards, Niklas

2016-09-09 13:37 GMT+03:00 Niklas Keller me@kelunik.com:

Most people think getting true random is a overkill and implement things
non-secure.

Most? Idk. But there certainly are many programmers that still believe
the myth that one should be conservative of the randoms. It's
nonsense. And uniqid() should either step aside or be properly random.

I just don't need true random here, just some form of replacing an integer
ID with a value, that cannot be changed just by "+1"

You can't have a "true" random -- at best you can have the kind of
pseudo-randomness the CSPRNG provides, which, btw, is ideal for this
purpose.

Another way of doing this is encrypt your predictable IDs. But this is
rather similar to using random IDs since the CSPRNG is using the key
stream of a symmetric encryption cipher.

That's exactly where uniqid SHOULD NOT be used. It's predictable. Anyone
can easily guess these URLs. If you want to prevent that, you should use
non-predictable secure random, also called cryptographically secure random:
CSRPNG. See random_bytes and random_int.

I agree with Niklas.

The way the system works and that this is a semi-closed tool for business
purposes, the only real thing why we need these ID's is to track people.
Before this plain numeric ID's from the DB records were used. With the
rewrite the client asked to make ID's so you can't just do a +1 and see
something different. No one will ever want to try and break the uniqid algo
just to get the other page (probably the same text). I also use the
extended version of the uniqid.

Sounds like old-fashioned "security through obscurity", where the level
of obscurity is somewhere between using strong crypto and trivially
predictable.

I don't think PHP should encourage it. There is no reason for it. If you
want unpredictability, there is no reason to hesitate to use
random_bytes() or random_int() as much as needed. You won't break anything.

Could you outline why you need 200 - 600 IDs in a single action?

Because it's a CSV import and I need to assign every record an ID at that
moment. Those ID's are then exported by admins to a 3rd party system.

Go ahead and read 64 KiB from random_bytes() if that's what you need.
It's safe and not worth your time to worry about it.

Sure, but for that you can as well just use microtime or time. As
shown, it's easily misused, you're the perfect example. :-)

microtime and time are easier to guess. And time() is not an option,
because I will get 600 equal ID's then. Microtime is an option, but then
you get number only string and it looks awfully sequential :) Hence the
uniqid usage, that is basically time + microtime if I understand from the
manual, but it generates a bit more random result and I'm sure I get a
unique value on every call. Improving it so it does not look awfully
sequential would suffice for the use cases it is needed. In my case this
was a clearly conscious choice with full understanding how it works.

You are free to devise your own algorithm for generating "somewhat
unpredictable" identifiers.

But PHP should not should not be involved. I think we should either
deprecate uniqid() or make it use php_random_bytes() and ignore its
second parameter.

Tom