PHP 7.1 - should we add a random_str() function?

Hi,

Le Wed, 30 Sep 2015 18:15:09 +0200, Scott Arciszewski
scott@paragonie.com a écrit:

This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

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.

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).

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

I'm interested, as I generate random strings for default passwords. I can
stay with my current system, but it would be sweet to shorten my code a
little bit :)

Regards.

This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

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.

I would propose a random_str() function that behaves similar to this
userland snippet: http://stackoverflow.com/a/32870871/2224584

Sounds great, and the amount of different answers on this stack overflow
question highlights the problem very well IMO.

Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

I screwed up sending this earlier. Sorry if you get this twice.

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

Hey Scott,

Scott Arciszewski wrote:

This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

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.

I would propose a random_str() function that behaves similar to this
userland snippet: http://stackoverflow.com/a/32870871/2224584

Generating random strings of characters is difficult, yeah, so this
seems useful. But I do wonder if this function is the right approach.
What if you have some other source of bytes and want to also produce a
sequence of characters matching some format?

What I think might be better is some bytes-to-arbitrary base conversion
function, one which lets you specify the character set to use. Then you
could use that with random_bytes(), but also with something else,
perhaps a public key? This way we don't have to duplicate the same
functionality somewhere else.

Thanks!

--
Andrea Faulds
http://ajf.me/

This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

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.

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).

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

--

Hey Scott

Just quickly for reference, there was some discussion on this before in
Feb, roughly here: https://marc.info/?l=php-internals&m=142481367620609&w=2

Not sure how relevant, havent reread it.