Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.123 as permitted sender)
To: Scott Arciszewski <scott@paragonie.com>,
 PHP Internals <internals@lists.php.net>
References: <CAKws9z3PBidEXQOZokomG-Y6GbfuefoTF=mXohJqZL=7w1xtGA@mail.gmail.com>
Message-ID: <560EF2AE.4080502@thefsb.org>
Date: Fri, 2 Oct 2015 17:10:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAKws9z3PBidEXQOZokomG-Y6GbfuefoTF=mXohJqZL=7w1xtGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: PHP 7.1 - should we add a random_str() function?
From: fsb@thefsb.org (Tom Worster)

I screwed up sending this earlier. Sorry if you get this twice.

On 9/30/15 12:15 PM, Scott Arciszewski wrote:
 > I think random_bytes() and random_int() are great; they provide a
 > much-needed building block in PHP 7.0. However, I do worry a bit that
 > the most common use for random_int() (generating a random string of a
 > fixed length with a given character set) will be reinvented over and
 > over again, and rarely consistently.

On one had I agree that it's a common use and put a method in Yii2's 
Security component for it (albeit less general then your proposal). But 
I'm not sure the motive you gave is sufficient to put it in PHP core.

We should be less concerned about people reinventing it over and over 
than people getting it wrong. The SO answer you referenced expresses 
exactly this concern. This was the motive for the new random functions 
and the password hash functions. It's a good argument.


 > I would propose a random_str() function that behaves similar to this
 > userland snippet: http://stackoverflow.com/a/32870871/2224584
 >
 > Function prototype:
 >
 >> string random_str( int $length, string $charset)
 >
 > Would return a string or throw an Error|Exception (e.g. invalid input
 > parameters, or the operating system's CSPRNG begins to melt).

If the problem is poor algorithms generating random strings that get 
"used for anything remotely analogous to a password" then I think this 
is not enough to be a solution. I think a class is needed that can do 
more including:

- Unicode characters. The $random_str .= $charset[$r]; line in the 
snippet you referenced implies a rather parochial tacit assumption. 
Passwords aren't always limited to Basic Latin.

- Constraints such as: exclude easily confusable characters such as 0 
and O, at least one digit, pronounceable, and things like that

- Choosing from a set of words (Diceware)

 From my own interactions with others, I know that people who shouldn't 
do in fact attempt to implement this kind of stuff. And that's to be 
expected because PHP apps very often need it.


 > I can write up an RFC for this, with a patch targeting 7.1, if anyone
 > is interested in it.
 >
 > Scott Arciszewski
 > Chief Development Officer
 > Paragon Initiative Enterprises <https://paragonie.com>
 >