Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88683
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.215.44 cause and error)
MIME-Version: 1.0
In-Reply-To: <560EF2AE.4080502@thefsb.org>
References: <CAKws9z3PBidEXQOZokomG-Y6GbfuefoTF=mXohJqZL=7w1xtGA@mail.gmail.com>
	<560EF2AE.4080502@thefsb.org>
Date: Mon, 5 Oct 2015 11:34:23 -0400
Message-ID: <CAKws9z1OpzdsbNcf7hcT2XF4yO12yJuKDDCNgdqSbhsOH+e6DA@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: PHP 7.1 - should we add a random_str() function?
From: scott@paragonie.com (Scott Arciszewski)

On Fri, Oct 2, 2015 at 5:10 PM, Tom Worster <fsb@thefsb.org> wrote:
> 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>
>>
>

You mentioned diceware. Incidentally,
https://paragonie.com/blog/2015/07/common-uses-for-csprngs-cryptographically-secure-pseudo-random-number-generators#diceware

Some problems (i.e. random_int) should be fixed at a language level.
Others, through education. In the end, this might be an education
issue.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>