[PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API

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 how you would like to see the API?
>
>
> I only have brainstorm thoughts on this, since I don't have a crystal
> ball.  What if characters other than a-zA-Z0-9./ should/can be used
> for some PASSWORD_xxx algorithms?  What if some seed is needed?  What
> if the salt creation algorithm should be swappable due to resource
> usage reasons, etc?

Actually... What about making the `raw_output` parameter a bitmask.
Then provide:

PASSWORD_SALT_CRYPT = 1
PASSWORD_SALT_RAW = 2

Then, in the future you could add a bunch of others PASSWORD_SALT_SOMETHINGELSE.

And you could combine some: PASSWORD_SALT_DEV_RANDOM, PASSWORD_SALT_WAHTEVER...

> Also, do you really need a php.ini parameter?  It's yet another
> potential way to attack a system.

Well, if not for an ini parameter, what way would you suggest to alter
the default bcrypt cost? (seriously, I'm open to suggestions)...


Thanks,

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi!

On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara <[email protected]> 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 wishes.

An ini setting for that sounds wrong to me.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Jul 3, 2012 at 10:42 AM, Pierre Joye <[email protected]> wrote:
> hi!
>
> On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara <[email protected]> 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 wishes.
>
> An ini setting for that sounds wrong to me.
Agree on this. We don't need any more ini settings. Having an
ini-setting would just force everyone to explicitly specify the load
parameter.

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 and PASSWORD_DEFAULT.

That way, over time, PASSWORD_DEFAULT could be updated, and it would
be documented that it would change. But it would require them to
understand that it could change...

Would that satisfy your issues?

Thanks,

Anthony

On Wed, Jun 27, 2012 at 8:12 AM, Pierre Joye <[email protected]> wrote:
> hi,
>
> On Wed, Jun 27, 2012 at 1:49 PM, Gustavo Lopes <[email protected]> wrote:
>> Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye <[email protected]>
>> 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 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. For any other and rather
> common cases, it won't. I do not think a default should be implemented
> and actually let the user knows what he uses and what he is doing.
> That's one argument after all and clears all possible caveats.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi Anthony,

On Tue, Jul 3, 2012 at 1:53 PM, Anthony Ferrara <[email protected]> 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 (algo) to password_hash required? That way users
> could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT.
>
> That way, over time, PASSWORD_DEFAULT could be updated, and it would
> be documented that it would change. But it would require them to
> understand that it could change...
>
> Would that satisfy your issues?

Yes.

Using this constant name and clearly document its changing nature is
fine. The argument being required fully solves my worry about optional
argument with changing default value.

Thanks for your efforts and work!

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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, over time, PASSWORD_DEFAULT could be updated, and it would
>> be documented that it would change. But it would require them to
>> understand that it could change...
>>
>> Would that satisfy your issues?
>
> Yes.
>
> Using this constant name and clearly document its changing nature is
> fine. The argument being required fully solves my worry about optional
> argument with changing default value.

I've implemented this in my branch. I've also updated the RFC to
indicate such (we may want to expand it a little bit, but it should
suffice for now).

I've also added a bit to the RFC about a policy for updating the
default constant over time. (Indicating for a non-security release,
changing the default must be done via an RFC, how long the algorithm
must be available before being eligible for default, etc).

> Thanks for your efforts and work!

Absolutely!

Thanks,

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 that's up to the application to decide. A
list of defaults does nothing but needlessly complicate the
implementation. How is the hash function supposed to determine which
of the list of defaults to use? Let the application layer choose, and
pass it in. The current PASSWORD_DEFAULT lives for the sole reason
that it auto-updates to indicate the most secure algorithm available.

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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, I'm not
convinced it's needed. Then again, it's easy to implement and shouldn't
pose a maintenance headache, so I'm not sure if it shouldn't be there
either...

What do you think?

Anthony

On Tue, Jul 3, 2012 at 5:24 PM, Anthony Ferrara <[email protected]> wrote:

> 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 that's up to the application to decide. A
> list of defaults does nothing but needlessly complicate the
> implementation. How is the hash function supposed to determine which
> of the list of defaults to use? Let the application layer choose, and
> pass it in. The current PASSWORD_DEFAULT lives for the sole reason
> that it auto-updates to indicate the most secure algorithm available.
>
> Anthony
>

hi Anthony!

On Mon, Jul 9, 2012 at 5:19 PM, Anthony Ferrara <[email protected]> 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 comparison is needed to know if an update is
necessary or not.

> password_get_info($hash)

Soungs good, to get all the details about the given hash.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 would prefer a password_rehash
> instead, then a simple comparison is needed to know if an update is
> necessary or not.
>
> > password_get_info($hash)
>
> Soungs good, to get all the details about the given hash.


The *only* problem with this is what happens if the options array contains
unused variables for an algorithm. Say we implement scrypt, and there's an
R variable in the array. If we check a bcrypt algorithm hash (with
PASSWORD_BCRYPT specifically), if the array contains "R", it could throw a
red herring indicating an un-necessary re-hash. So there's some algorithmic
specific information that needs to be compared. Thereby making a
"needs_rehash" function in userland non-trivial. It's still not complex,
but it's not trivial either. Part of me wants to see it as it would be
maintained over the years as new algorithms are introduced, and hence can
compensate for other things that implementing it in userland can't....

In other words, I'm not sure either way...

Anthony

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 secure' but 'better/recommended' since the attacker would need to create a 'rainbow table' for each password it's trying to crack
Overall, the technique offers better protection.

b) In terms of 'effort' to break a single password, there's **no** benefit to the salt stored in the hash itself.

If you want a single password to be really secure, don't let the attacker know the salt and keep it long:

// no benefit of short salt, ~ same effort required by the attacker
$password = '234';
md5($password);

$salt = '1';
$password = '234';
md5($salt . $password);

c) The best of both worlds: long private salt (b) + different for every user (a)
$saltInpassword = $password[0]; // could be random bytes, stored in password like crypt() does
$salt = 'my-long-private-value-use-all-bytes'. $saltInPassword;
$password = '234';
$hash = md5($salt . $password);

This one requires more effort by the attacker since the long salt forces more 'bits/guesses' to pass into md5()

// require even more effort, iterate
for($i = 0; $i < 1000; $i++)
$hash = md5($i . $hash);




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

On Tue, Jul 31, 2012 at 2:02 PM, Jonathan Bond-Caron <[email protected]> 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 would need to create a 'rainbow table' for each password it's trying to crack
> Overall, the technique offers better protection.
>
> b) In terms of 'effort' to break a single password, there's **no** benefit to the salt stored in the hash itself.
>
> If you want a single password to be really secure, don't let the attacker know the salt and keep it long:
>
> // no benefit of short salt, ~ same effort required by the attacker
> $password = '234';
> md5($password);
>
> $salt = '1';
> $password = '234';
> md5($salt . $password);
>
> c) The best of both worlds: long private salt (b) + different for every user (a)
> $saltInpassword = $password[0]; // could be random bytes, stored in password like crypt() does
> $salt = 'my-long-private-value-use-all-bytes'. $saltInPassword;
> $password = '234';
> $hash = md5($salt . $password);
>
> This one requires more effort by the attacker since the long salt forces more 'bits/guesses' to pass into md5()
>
> // require even more effort, iterate
> for($i = 0; $i < 1000; $i++)
> $hash = md5($i . $hash);

This is somehow the 1st implementation (part of) of crypt. See
ext/standard for the full code. And md5 is now known to do not be
secure enough. IIRC.

I would not, but really totally not, begin to try to implement our own
little algorithm but rely on standard well tested implementations.
Crypt support blowfish, for example. Anthony also works on supporting
more algos afair.


Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php