Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94881
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.163 cause and error)
MIME-Version: 1.0
In-Reply-To: <9d2ef6f3a84333f35ebcb843ade65c22@k-piste.dy.fi>
References: <CAGC=tRnpka_ym=f-xsskjeiPaqahsTEAxPq9=E8Z73KQKeRrHg@mail.gmail.com>
 <81b5a129-9c90-0a54-921f-7e1f9b5f727f@thefsb.org> <CAGC=tR=4v0KAkqnU1Q3Fr5AeM8o_PuJfP9rYQ_s4X3=Z9UUh=w@mail.gmail.com>
 <CAObuZdsq33=g4wG=FP0bOHnsE9N+PrCu3nGs7ZNAxx=rX4dJ+w@mail.gmail.com>
 <CAGC=tRkw3u0=ufjALKvF6YpahLE6H05T0vFBHyHPCM4aR1siCw@mail.gmail.com>
 <D3CA3C50.70BAD%fsb@thefsb.org> <CAGC=tRnKgD=r8pSc1KVPahC2Xx=BYDV+M=55eQ0GfMQSVgr97Q@mail.gmail.com>
 <9d2ef6f3a84333f35ebcb843ade65c22@k-piste.dy.fi>
Date: Sat, 6 Aug 2016 13:09:05 +0200
Message-ID: <CANUQDCj-e27+VS0uZPXcOw=Y4mVNwR23AFE9btaNA3VXqKTAcQ@mail.gmail.com>
To: =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>
Cc: "Charles R. Portwood II" <charlesportwoodii@erianna.com>, Tom Worster <fsb@thefsb.org>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7ba97a101a859c0539653647
Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Argon2 Password Hash
From: me@kelunik.com (Niklas Keller)

--047d7ba97a101a859c0539653647
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-08-05 22:51 GMT+02:00 Lauri Kentt=C3=A4 <lauri.kentta@gmail.com>:

> On 2016-08-05 21:20, Charles R. Portwood II wrote:
>
>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <fsb@thefsb.org> wrote:
>>
>>>
>>> I can understand an argument that it's too much to expect a user to
>>> provide an options array when using Argon2. But I don't understand how =
my
>>> suggestion breaks BC. In my idea, a future RFC would propose default co=
st
>>> constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on tho=
se
>>> constants so they would need to be defined before changing
>>> PASSWORD_DEFAULT or at the same time. So...
>>>
>>> password_hash('password', PASSWORD_DEFAULT) will always work.
>>>
>>> password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is
>>> introduced in your proposal, but has to wait for another future RFC in =
my
>>> suggested change.
>>>
>>> password_hash('password', PASSWORD_ARGON2I, [costs]) will always work.
>>>
>>> How does a BC break happen?
>>>
>>> Tom
>>>
>>>
>> Hi Tom,
>>
>> It breaks the API in the interim between this RFC and a potential future
>> one. The $options parameter for both password_hash and
>> password_needs_rehash is optional. Making it required for one algorithm
>> but
>> not another changes the API's for both methods. The expectations outline=
d
>> in the original password_hash RFC make the third parameter for tuning th=
e
>> algorithm, not for making the algorithm work. Without default values, bo=
th
>> password_hash and password_needs_rehash would fail unless the costs are
>> provided.
>>
>>
> I think it's very important to provide some kind of default parameters.
> We have password_needs_rehash for the exact reason that we can later
> change the defaults if they are not good enough (anymore).
>
> If the defaults are not set, people will have to invent their own
> parameters, which may be good or very bad. These parameters will not be
> automatically updated with future versions of PHP.
>

We should definitely provide defaults.


> There is nothing to lose from setting some sane defaults.
> There is nothing to gain from NOT setting the defaults.
>
> About the memory requirements: setting the memory cost too high may limit
> using this algorithm in many inexpensive shared web hosting services,
> which may have default PHP memory limit as low as 128 MB or 256 MB.


Setting the memory limit too high could also result in overall memory
exhaustion with many concurrent login attempts.

--047d7ba97a101a859c0539653647--