Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102101 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44999 invoked from network); 11 May 2018 10:37:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2018 10:37:01 -0000 Authentication-Results: pb1.pair.com smtp.mail=alice@librelamp.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=alice@librelamp.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender) X-PHP-List-Original-Sender: alice@librelamp.com X-Host-Fingerprint: 45.79.96.192 librelamp.com Received: from [45.79.96.192] ([45.79.96.192:36508] helo=librelamp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/8B-47313-B4275FA5 for ; Fri, 11 May 2018 06:37:00 -0400 Received: from localhost.localdomain (92.sub-174-215-7.myvzw.com [174.215.7.92]) by librelamp.com (Postfix) with ESMTPSA id 0F8122675 for ; Fri, 11 May 2018 10:36:57 +0000 (UTC) To: internals@lists.php.net References: Message-ID: Date: Fri, 11 May 2018 03:36:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Deprecation of uniqid() From: alice@librelamp.com (Alice Wonder) On 05/11/2018 01:59 AM, Arvids Godjuks wrote: > 2018-05-10 16:33 GMT+02:00 Niklas Keller : > >> Hey, >> >> I hereby propose to deprecate uniqid(). There have been attempts to fix it >> ( >> https://wiki.php.net/rfc/uniqid), but those were rejected during >> discussion, because there's no possible fix without breaking BC. Instead of >> a subtle BC break, this RFC favors the deprecation and moving users to >> other functions. >> >> It's to be discussed whether the function should be removed with PHP 8.0 or >> just deprecated to avoid fully breaking things where it's not strictly >> necessary. A deprecation will probably avoid most new usages, which is the >> main goal. >> >> RFC: https://wiki.php.net/rfc/deprecate-uniqid >> >> Kind Regards, >> Niklas >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Hello, > > as a userland user of this function I do disagree with it's outright > removal. It has it's uses. > What can be done with it is drop the $more_entropy flag and make it > generate at least as long strings and use random_bytes under the hood for a > better random. > It can also adopt a length parameter so you can vary the random part as > much as you need it. > > You don't always need a truly random token - I have a system that uses > uniqid to generate tens of thousands tokens per request and it's actually a > good thing they are time based at the start of it with a random part at the > end (as I said the random part should be improved and get rid of that > stupid dot when generating with $more_entropy = true). > It seems to me that for your use case, you could just use the time() function to get part of your unique id and then use libsodium to generated a nonce for the "random" part, using sodium's function for increment the nonce between each use. Predictable, sure, but your use case says they don't need to be a truly random token - just unique (essentially a non-random nonce) but with a time component.