On 9/9/16 7:18 AM, Arvids Godjuks wrote:
2016-09-09 13:37 GMT+03:00 Niklas Keller <m...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
