[RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Scott Arciszewski wrote on 23.08.2015 02:50:

Anthony Ferrara wrote on 22.08.2015 21:58:

All,

I am putting a simple RFC up for discussion to make random_* throw
exceptions on failure in order to ensure we fail-closed.

https://wiki.php.net/rfc/random-function-exceptions

Considering this topic has already been discussed, I intend to open
voting on this as soon as allowable. Given the voting policy specifies
2 weeks for language changes and 1 week for another, this is assumed
to require 1 week of "discussion".

With that in mind, I intend to put this RFC up to vote on August 29/30th.

Thanks!

Anthony

--

Hi,

I think there are a lot of security problems if people ignore return values,
e.g. password comparison, user lookup in database, lookups for permissions,
etc.

Having false + E_WARNING highlighted in the documentation with a yellow box
and the Caution title should be enough.

For those who want exceptions can implement this in userland:
$rand = random_int(10,100);
if ($rand === false) {
throw new Exception('error ...');
}
// or write a wrapper like random_int_exception(...).

If people use this function without reading documentation, they will also use
other things without documentation like database queries without
binding/escaping, inject html without escaping, etc.
Having core functions suddenly throw exceptions causes many problems in the
code structure.

Regards
Thomas

--

Hi Thomas,

Your proposal effectively blames the user if they get it wrong and
burdens them with additional responsibilities. Increasing the
cognitive load of PHP developers will not result in a net gain for the
security of the applications they develop. I've made this argument
elsewhere in the course of this discussion.

Cryptography implementations should do everything reasonable to not
blame the user, and cryptographic primitives should do everything
reasonable to not blame the implementor.

Read this: http://cr.yp.to/talks/2015.01.07/slides-djb-20150107-a4.pdf

If people use this function without reading documentation, they will also use
other things without documentation like database queries without
binding/escaping, inject html without escaping, etc.
Having core functions suddenly throw exceptions causes many problems in the
code structure.

Exceptions will only be thrown in exceptional circumstances:

1. If they're using shared hosting, and a malicious script triggers a
   file descriptor exhaustion condition on another hosting account (we're
   assuming great sandboxing between customers), an exception will be
   thrown rather than returning FALSE.
2. If the system is utterly incapable of generating random numbers.

An exception must either be handled (try-catch), or it by default
terminates script execution. This is the best of both worlds:

1. It fails closed.
2. It's easy to handle gracefully should the developer wish to do so.

Designing a CSPRNG that will fail closed, without unavoidably killing
their script (i.e. E_ERROR), will do far more to make PHP applications
secure than telling people they should RTFM.

Hackers have been saying RTFM since the ARPANET days, and yet most
people still don't. It's a losing battle. Let's patch what we can with
good design decisions.

TL;DR - the path forward is Throwable. Whether it's an Error object or
and Exception object (and when it throws which) is what's to be
discussed and voted on.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com

why not have false + e_warning for strict_types=0 and fatal error for strict_types=1 ?
Doing function random_int(): int { ...

Regards
Thomas