Allow access to default cost parameter about password_compat HOT 5 CLOSED

Kinda makes sense, though I don't know how often people will actually end up being in that relatively small target demographic of "I want more cost than the default now, but php may bump the default cost up to more than mine later".

from password_compat.

This argument makes no sense to me at all.

Either you care about fine-tuning bcrypt, or you don't. This idea of “I want to maximize security now, but in the future, I'll just go with whatever the default value is” seems rather weird to me.

Personally, I see no reason for exposing the default cost factor. Either you rely on the function to take care of the right value. Or you pass your own carefully chosen value to it and update it as time goes by.

from password_compat.

Anecdotally, I've seen people bump the cost to 11 or 12 at the start of a new project, after reading a couple of blog posts suggesting that 10 isn't best practice any more. In all likelihood, this setting won't get changed in the application again (developers make configuration mistakes - they aren't perfect), but PHP's default will get updated. Overriding and having to maintain the default cost is a technical debt that some developers don't even consider but if a developer hears "10 is insecure, use 11 or 12" they're going to bump it up straight away.

Realistically, I think "PHP may bump the default cost up to more than mine later" is very likely to start happening in a few years time; especially with legacy code and unsupported frameworks.

Objectively, there is a use case for this and I can't see any downsides to users. However I understand there is work involved in developing this, so if the use case is perceived to be too small then feel free to close the issue.

from password_compat.

In a bcrypt implementation for an employer, I actually wrote a bit of logic to accommodate Moore's Law:

$cost = 10 + ceil( (date('Y') - 2010) / 3);

Using something like max($cost, PASSWORD_BCRYPT_DEFAULT_COST) would be useful if your threat model includes "the attacker is able to reset the clock to 1970", but mine doesn't. 😄

from password_compat.

Fixed with #69

from password_compat.