Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZYStrud9MWya-680Z457T1i-a2F5u-AXtaNvkTdMEZtQ@mail.gmail.com>
References: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org> <CAGa2bXZYStrud9MWya-680Z457T1i-a2F5u-AXtaNvkTdMEZtQ@mail.gmail.com>
Date: Mon, 30 Jan 2017 11:25:35 +0900
Message-ID: <CAGa2bXZRT2xGgL7fMkHFetjDk00w=AMmaCipVeM5Oftvd0mYAw@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>, =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>, 
	Leigh <leight@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11444e804223cd0547468a12
Subject: Re: [PHP-DEV] Re: Improving mt_rand() seed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11444e804223cd0547468a12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Mon, Jan 30, 2017 at 10:08 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Issues are
>> - Current mt_rand() is not fully exploited. It wastes more than 99% of i=
ts
>> random cycle.
>>
>> This was discussed in Aug last year and dropped.
>>
> I didn't notice the discussion, let's discuss again.
>
> It does not make sense to discard more than 99% of cycle. In addition, MT
> rand reference implementation is capable to initialize whole state buffer=
,
> why we shouldn't have it?
>

First of all, users should never use mt_rand() for any security related
purposes.
However, there are too many codes that use mt_rand() for the purpose.

MT rand is a lot harder to predict than older predictable PRNG. Many users
misunderstood
it as "secure like CSPRNG" because it is advertised "very secure and hard
to predict
than older PRNG" too much.

Attackers can get "mt_rand() generated random string" very easily on many
apps.
Apps generate access token by mt_rand() is just a matter of requesting
proper
apps' feature. e.g. password generated by mt_rand(), access token generated
by mt_rand().

With ideal implementation, attackers must search random sequence from
2^19937=E2=88=921 cycle,
but they can guess random sequence easily because PHP's mt_rand() has
only 2^32 initial states.
It's far less than 1% of MT rand capability. This allows attackers to guess
"mt_rand()
generated random  string" easily than it could be.

Attackers may get victim's correct password with combination of "getting
mt_rand() generated
password" and "social engineering", e.g. Notify victim "Your account is
compromised,
please reset your password. Please make sure to use system generated strong
random
password".

Exploiting Access token that allows access to system by itself could be
even easier.
Attackers generate mt_rand() created access token and guess next access
token to
be generated, then use the access token that is owned by poor victim.

_Mainly_, it is users fault because mt_rand() should never be used for
above purpose, but
mt_rand() generated random string being extremely weak than it could be is
our fault.

Our part could be fixed by us. Let's fix it now.

Lauri made patch for unseeded mt_rand(). I'll prepare patch that allows int
array
initialization for mt_srand() so that whole state buffer can be initialized
as user specifies.

void mt_srand(int|array $seed)

where $seed could be

$seed =3D [123456789, 987654321, ....]; // Up to max size of state buffer

It can be said current mt_rand() is good enough for the purpose. I totally
agree with this.
However, I cannot agree that current mt_rand() implementation is ideal/what
is should be.

Any comments?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11444e804223cd0547468a12--