Hi Kazuo, On Tue, Sep 13, 2016 at 11:48 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> Current "more_entropy" part (10 bytes) pattern is "n.nnnnnnnn" and its >> variation is 10^9 (1 billion) as written in your RFC. (about 30bits?) >> >> I think it is enough to avoid collision in the same usec, for >> non-security purpose. > > Oops. Thank you for the correction :) I'll fix the RFC.
Oops again. I wrote correctly in RFC. Typo was in mail. >> >>> How serious BC is? >> >> You should already know that this BC-breack breaks existing >> valid PHP codes in some situation. (DB error, test failure, etc.) >> >> BC-breack may be acceptable if the change is clearly greate improvement >> or obviously necessary. But this change is not, I think. > > I do think this is needed. > > Let's not please security audit companies. Use of current uniqid() in > security sensitive context is fatal because it is too easy to predict > generated ID even with "more_entropy". Letting make such mistake > moderate is worth the change. In short, making PHP be more secure platform (tolerant even for mistakes) matter to me. This BC is nothing compared to mt_rand() everywhere. Anyway, let's talk BC with real code. I didn't look into all, but only briefly. https://searchcode.com/?q=uniqid&loc=0&loc2=10000&lan=24 I could only find one code that tests uniqid() return value to test uniqid() (?) Other than that, almost all code does not care about uniqid() return value at all. Who cares about uniqid() return value? for what purpose? other than testing uniqid() itself? Even if some test code breaks, does it worth than making PHP be more secure platform? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
