Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56981
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CB176617.204DC%fsb@thefsb.org>
References: <CB176617.204DC%fsb@thefsb.org>
Date: Wed, 21 Dec 2011 11:19:19 -0500
Message-ID: <CAAyV7nE7pdDqhCW+Xt2Fpr0M=xvm0D_GM5T9RCKoAt+9it2QaA@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] CS random values
From: ircmaxell@gmail.com (Anthony Ferrara)

Tom,

First off, very detailed post!  However, there are a few things I'd
disagree with.

1. Salts for crypt() purposes need to be cryptographically secure
random numbers.

This is not true.  The only requirement is that a salt be reasonably
unique (meaning that the chance of using the same one is pretty low
for the scale of the application.  See this:

http://security.stackexchange.com/a/7195

CS random salts are needed for certain signing algorithms.  But not
for password storage.

Now, there is a need for CS Random numbers in general.  Things like
key generation (which shouldn't be done in PHP to begin with), Nonces
and One-Time Pads require secure random numbers.  But in general, most
uses in PHP would suffice with a normal quality PRN.

2. I was unable to do it.

I did it fine.

https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random

It's an RFC4086 compliant CSPRNG
(http://tools.ietf.org/html/rfc4086#section-5.2).  It uses multiple
sources to generate the final number, and mixes them together using
cryptographically secure methods.  Sure, in a perfect storm situation
(Linux, Safe Mode, without OpenSSL, without MCrypt, etc) it would only
use mt_rand() + rand() + uniqid() + microtime(), which is still pretty
secure (in the sense that both bias and predictability are both
virtually non-existent due to the mixing step).

3. My proposal is to put a new function into basic_functions along
side mt_rand(). I suggest naming it cs_rand()

I would be against this proposal.  CS random numbers are something
that shouldn't be over used.  Otherwise you can wind up either running
out of entropy on the system (causing blocking while more is
"gathered") or reducing the quality of the random numbers.  I don't
think normal developers understand the difference and when each is
required.

I would be for a proposal to add a salt generation function though
(similar to BCrypt.gensalt()).

Thanks,

Anthony

On Wed, Dec 21, 2011 at 10:31 AM, Tom Worster <fsb@thefsb.org> wrote:
> Hi, I'm new to this list so please tolerate my unfamiliarity with
> protocol.
>
> PHP does not in general allow access to the underlying system=B9s
> entropy source. I think it would be a good idea if it did.
>
> It is routine for web developers to write code in PHP that stores
> passwords in database tables or other persistent stores. In these
> cases a one-way hash is generally used (and PHP=B9s crypt() is very
> good here). In such schemes, the password must be salted to
> protect against known hash lookups. But the salt must be a
> **cryptographically secure** random value. (This is just one
> example of when a CS random value is needed, but a very common
> one.)
>
> I recently attempted to write a function in PHP that would return
> CS random bytes from the system=B9s entropy source. I was unable to
> do it.
>
> 1. /dev/random and /dev/urandom are unavailable on Windows and
> cannot be fopen()=B9ed in safe mode on *nix/nux
>
> 2. openssl_random_pseudo_bytes() requires openssl extension
> installed and enabled. Most of the popular AMP packages for
> Windows fail on this count. Many shared web hosts don=B9t have it
> either.
>
> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
> similar problems as openssl
>
> 4. Another method is to set runtime config param
> session.entropy_length followed by @session_start();
> session_regenerate_id(); after which session_id() will return a
> CS random string, but this is also foiled by safe mode.
>
> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
> but that API is obsolescent and not in many default Windows
> installs.
>
> 6. Last chance is new DOTNET('mscorlib',
> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc
> requires a working and compatible .NET framework.
>
> At this point the best bet is probably to hash some bytes from
> mt_rand() with microtime() and return that but trigger a warning
> about security. This is a very poor substitute.
>
> And given the routine need for CS random numbers in PHP
> applications, it is, in my view, not satisfactory.
>
> My proposal is to put a new function into basic_functions along
> side mt_rand(). I suggest naming it cs_rand(), cs being mnemonic
> for crypto secure. It should appear in the same sections of the
> manual as mt_rand() and rand() and both of those manual entries
> should call out the fact that they are not crypto secure and refer
> to cs_rand().
>
> I propose an implementation broadly similar to mcrypt_create_iv(),
> see php-5.3.8/ext/mcrypt/mcrypt.c lines 1373 thru 1434. (Even
> though I haven=B9t programmed in C since the 1980s, this doesn=B9t
> look hard.)
>
> But I suggest a different signature. openssl_random_pseudo_bytes()
> is a better model. mcrypt_create_iv()=B9s $source argument should be
> avoided, it just confuses the user.
> openssl_random_pseudo_bytes()=B9s &$crypto_strong response is
> valuable. I would also consider triggering a PHP warning when a
> non-crypto strong value is returned.
>
> I would be happy to help with the work. I=B9m not sure I=B9d do a good
> job with the implementation because I haven=B9t programmed inside
> PHP before while an experienced internist could do it very
> quickly. But I may be able to help with test cases and
> documentation.
>
> Warm regards
> Tom
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>