hi,
On Tue, Jul 31, 2012 at 2:02 PM, Jonathan Bond-Caron wrote:
> On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
> a) In terms of 'effort' to break many passwords, there's a benefit to the
> salt stored in the hash itself.
> It's not 'more secure' but 'better/recommended' since the attacker woul
On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
> because at the moment i do not understand how salt stored in the hash itself
> makes hash more
> secure than an unsalted one.
a) In terms of 'effort' to break many passwords, there's a benefit to the salt
stored in the hash itself.
It's not 'more
Pierre,
> I've added a pair of new functions to the RFC and implementation:
> >
> > password_needs_rehash($hash, $algo, array $options = array())
>
> Not totally convinced about that one.
I'm not either. That's why I added the discussion point around it. I can
see it going either way.
> I woul
hi Anthony!
On Mon, Jul 9, 2012 at 5:19 PM, Anthony Ferrara wrote:
> I've added a pair of new functions to the RFC and implementation:
>
> password_needs_rehash($hash, $algo, array $options = array())
Not totally convinced about that one. I would prefer a password_rehash
instead, then a simple c
I've added a pair of new functions to the RFC and implementation:
password_needs_rehash($hash, $algo, array $options = array())
and
password_get_info($hash)
both are reasonably similar and there's a fair bit of overlap. Considering
that password_needs_rehash can be implemented easily in user-land
Richard,
> There is also the case of an app that simple shouldn't run with the
> single default, but could pick and choose suitable algorithm from a
> list of defaults, while still honoring whatever is in the .ini file
> instead of going rogue with some other algorithm.
I disagree there. I think
Pierre,
>> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to password_hash required? That way users
>> could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT.
>>
>> That way, ov
hi Anthony,
On Tue, Jul 3, 2012 at 1:53 PM, Anthony Ferrara wrote:
> Pierre,
>
> Getting back to the PASSWORD_DEFAULT discussion...
>
> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
> PASSWORD_DEFAULT as a moving target, documented, and just making the
> second parameter (alg
Pierre,
Getting back to the PASSWORD_DEFAULT discussion...
I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
PASSWORD_DEFAULT as a moving target, documented, and just making the
second parameter (algo) to password_hash required? That way users
could choose between PASSWORD_BCRYPT
Pierre,
> Simply by not allowing to change it. If one does not like it, it can
> pass the option value as he wishes.
>
> An ini setting for that sounds wrong to me.
Alright. I've pulled the ini option from the fork, and have updated
the RFC to the same...
Anthony
--
PHP Internals - PHP Runtime
On Tue, Jul 3, 2012 at 10:42 AM, Pierre Joye wrote:
> hi!
>
> On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara wrote:
>
>> Well, if not for an ini parameter, what way would you suggest to alter
>> the default bcrypt cost? (seriously, I'm open to suggestions)...
>
> Simply by not allowing to change
hi!
On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara wrote:
> Well, if not for an ini parameter, what way would you suggest to alter
> the default bcrypt cost? (seriously, I'm open to suggestions)...
Simply by not allowing to change it. If one does not like it, it can
pass the option value as he
Chris,
> To be honest, a note next to PASSWORD_DEFAULT would be good too.
Ok, I'll add that in shortly.
>>> The API of password_make_salt() seems restrictive. What if other
>>> options are needed in future?
>>
>>
>> Can you give any examples of what options would be needed in the
>> future, or
On 07/02/2012 01:55 PM, Anthony Ferrara wrote:
Chris,
Can you update the RFC (aka future documentation) and make this obvious
to an end user?
I just made an update (in the behavior sections). Let me know if
additional clarification is needed.
To be honest, a note next to PASSWORD_DEFAULT
Chris,
> Can you update the RFC (aka future documentation) and make this obvious
> to an end user?
I just made an update (in the behavior sections). Let me know if
additional clarification is needed.
> I think PASSWORD_BCRYPT should be an ordinal value, which the new
> library maps to "2y" when
On 06/26/2012 08:25 AM, Anthony Ferrara wrote:
Hello All,
I've taken the conversation of the previous simplified password
hashing API, and generated a patch and draft RFC for it. The patch
isn't ready yet (needs review, cleanup and testing), but it's a start.
https://wiki.php.net/rfc/password
On 06/27/2012 07:16 AM, Anthony Ferrara wrote:
Arvids,
On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
wrote:
Hello.
I personally think that using PASSWORD_DEFAULT for algorythm by default is a
bad idea. This should be defined by user in the code. Even worse if it is
defined by .ini setting
hi Anthony,
On Thu, Jun 28, 2012 at 9:36 PM, Anthony Ferrara wrote:
>> I haven't looked at your patch. But if it has to call another
>> PHP_FuNCTION then it's not good. crypt implementation should be
>> accessible via C.
>
> I've refactored crypt() slightly to expose a PHP_API crypt_execute()
>
Johannes,
> I haven't looked at your patch. But if it has to call another
> PHP_FuNCTION then it's not good. crypt implementation should be
> accessible via C.
I've refactored crypt() slightly to expose a PHP_API crypt_execute()
function that does just about everything except the argument parsing
On Wed, 2012-06-27 at 22:00 -0400, Anthony Ferrara wrote:
> Johannes,
>
> > Some comments on the "error behavior" part:
> >
> >E_WARNING - When CRYPT is not included in core (was disabled
> >compile-time, or is listed in disabled_functions declaration)
> >
> > Disabling a different functio
Hi Anthony!
On Thu, Jun 28, 2012 at 4:00 AM, Anthony Ferrara wrote:
> Hrm. Well, then I guess I could re-implement against crypt internally.
> That would take either a slight re-implementation of the crypt()
> internals, or slight refactoring of the PHP_FUNCTION(crypt) function
> to enable c cal
hi,
On Thu, Jun 28, 2012 at 12:03 AM, Ángel González wrote:
> Precisely the point of such constant is to allow the applications to
> magically
Right, but not a default argument, which is bad in this case, for the
reasons explained earlier.
> Obviously, any such bump -which I would expect to ha
Pierre,
> No, it is exactly one example out of many where changing values are a
> real pain to deal with over the years. We should not have one.
While I completely see your point (and don't disagree with it in
isolation), I also see the counter point of making it easy for people
to use. Knowing a
Johannes,
> Some comments on the "error behavior" part:
>
> E_WARNING - When CRYPT is not included in core (was disabled
> compile-time, or is listed in disabled_functions declaration)
>
> Disabling a different function should have no effect. This is not
> intuitive. If crypt is a dependency
Arvids,
On Wed, Jun 27, 2012 at 12:32 PM, Arvids Godjuks
wrote:
> On that note I have only one request - please point me to the good article
> that describes how this thing works (I would prefer one that at least tries
> to explain in simple words) because at the moment i do not understand how
>
On 27/06/12 18:13, Pierre Joye wrote:
> Changing default value forces code change if you have to keep a given
> hash, for one obvious side effect.
>
> If you disagree or does not like the idea, that's all fine, but you
> can't really say that it is not an argument (nothing to justify, this
> is a d
Hi,
On Tue, 2012-06-26 at 11:25 -0400, Anthony Ferrara wrote:
> https://wiki.php.net/rfc/password_hash
Some comments on the "error behavior" part:
E_WARNING - When CRYPT is not included in core (was disabled
compile-time, or is listed in disabled_functions declaration)
Disabling a diffe
On that note I have only one request - please point me to the good article
that describes how this thing works (I would prefer one that at least tries
to explain in simple words) because at the moment i do not understand how
salt stored in the hash itself makes hash more secure than an unsalted one
hi,
On Wed, Jun 27, 2012 at 2:59 PM, Gustavo Lopes wrote:
> You described why people *may* have to, depending on the circumstances --
> for instance, when interoperability in mixed environments is required. No
> one is saying that relying on a default value is appropriate in those
> circumstance
Arvids,
On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
wrote:
> Hello.
>
> I personally think that using PASSWORD_DEFAULT for algorythm by default is a
> bad idea. This should be defined by user in the code. Even worse if it is
> defined by .ini setting - deploy to a remote server and realize th
Hello.
I personally think that using PASSWORD_DEFAULT for algorythm by default is
a bad idea. This should be defined by user in the code. Even worse if it is
defined by .ini setting - deploy to a remote server and realize that there
is a different .ini default that messes up everything. Lessons le
Pierre,
> Back then MD5 alone was all nice and shiny. So no, it is not possible
> to be forward compatible.
By forward compatible, if you mean able to support any new algo, I
think this is forward compatible. The options array allows for new
implementations to implement whatever options they need
Em Wed, 27 Jun 2012 14:43:35 +0200, Pierre Joye
escreveu:
On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes
wrote:
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
escreveu:
I don't see any advantage in adding complexity through another level of
indirection. If people want control ove
hi,
On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes wrote:
> Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
> escreveu:
>
>
>> Actually, now that I'm talking that out, perhaps the way to do it
>> would be to specify the default algorithm in a php.ini parameter
>> instead of the constant? Tha
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
escreveu:
Actually, now that I'm talking that out, perhaps the way to do it
would be to specify the default algorithm in a php.ini parameter
instead of the constant? That way the API can stay the same, but gives
people more control over the
Pierre,
>> As I understand, hashes computed with the old default method could still be
>> checked without any modification as the hash itself stores information about
>> the method.
>
> That's only about one relatively simple use case where only PHP would
> be involved or crypt-like implemenation.
hi,
On Wed, Jun 27, 2012 at 1:49 PM, Gustavo Lopes wrote:
> Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye
> escreveu:
>
>
>> That's exactly what I meant, having a changing default in this may
>> force code change during php updates. I'm not in favour of having such
>> default.
>>
>
> This woul
Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye
escreveu:
That's exactly what I meant, having a changing default in this may
force code change during php updates. I'm not in favour of having such
default.
This would not require any code changes after updates.
As I understand, hashes compu
hi,
On Wed, Jun 27, 2012 at 1:24 PM, Anthony Ferrara wrote:
> Simon,
>
>> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever?
>> Otherwise this lib, in my opinion, can cause big problems when trying to
>> port an existing system to a newer PHP-version.
>
> the default is
Simon,
> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever?
> Otherwise this lib, in my opinion, can cause big problems when trying to
> port an existing system to a newer PHP-version.
No. That's why it's a separate constant. As newer, stronger hashing
options become avai
hi!
On Wed, Jun 27, 2012 at 12:13 PM, Simon Schick wrote:
> Hi, Anthony
>
> Some questions coming up in my mind by reading this RFC:
>
> * Will the value of the constant *PASSWORD_DEFAULT* remain unchanged
> forever? Otherwise this lib, in my opinion, can cause big problems when
> trying to port
Hi, Anthony
Some questions coming up in my mind by reading this RFC:
* Will the value of the constant *PASSWORD_DEFAULT* remain unchanged
forever? Otherwise this lib, in my opinion, can cause big problems when
trying to port an existing system to a newer PHP-version.
* Is this a native version of
Hello All,
I've taken the conversation of the previous simplified password
hashing API, and generated a patch and draft RFC for it. The patch
isn't ready yet (needs review, cleanup and testing), but it's a start.
https://wiki.php.net/rfc/password_hash
Please have a look and comment away!
Thanks
43 matches
Mail list logo
