On 12 Oct 2023, at 19:50, Jordan LeDoux wrote:
> That's not how voting works in the PHP project. The 2/3 is for whether or not
> the feature change should be made at all. In the case that there are multiple
> implementations or variations, the choice between those is usually simple
> majority.
On Wed, Oct 4, 2023 at 5:08 PM wrote:
> Also the poll for increasing from cost 11 to cost 12 should be a 2/3
> majority to get cost 12. Since the poll for increasing from cost 10 to cost
> 11 is a 2/3 majority. You can think of this as a 2/3 majority poll to
> increase to cost 11 followed by a
Hi
Let me link your Fediverse reply for reference as well:
https://infosec.exchange/@sc00bz/78818937154254
On 10/5/23 02:07, st...@tobtu.com wrote:
I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12
is ~1 kH/s/GPU and the accepted limit for good settings
Hi
On 9/21/23 19:26, Tim Düsterhus wrote:
I just opened the vote for the "Increasing the default BCrypt cost" RFC.
The RFC contains a two votes, one primary vote that requires a 2/3
majority to pass and a secondary vote deciding on the new costs with a
simple majority. Voting runs 2 weeks until
> On 09/22/2023 2:04 AM CDT Nicolas Grekas wrote:
>
>
> I was wondering if you considered also raising the Argon2 default cost? Has
> this been discussed?
>
Argon2 defaults are actually quite high at a theoretical speed of ~1.3 kH/s/GPU
(960,000,000,000/(64*1024^2)/(3*4-1) or in general
I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost
12 is ~1 kH/s/GPU and the accepted limit for good settings is <10 kH/s/GPU.
Cost 12 is 10x stronger than it needs to be as a *minimum*. I believe cost 10
is a good *default* for the next 1-3 years and cost 11 should
On 25 Sep 2023, at 18:07, Tim Düsterhus wrote:
> I've now did the maths and you really need rate limiting no matter if you use
> costs 10, 11 or 12, so I believe the DoS argument is a little moot.
Yes, someone being malicious could easily generate enough requests to create an
Denial of
Hi
On 9/25/23 21:43, Levi Morrison via internals wrote:
I did a tiny bit of my own research, and could not find any
recommendations more specific than "10 or more" as the cost factor.
Typically, the advice is "use a more modern system like argon2id".
Please see this email of mine regarding
Yes, BCrypt uses only the first 72 bytes for hash generation. You can
test it with:
var_dump(password_verify(str_repeat('a', 72).'sdfsdf',
password_hash(str_repeat('a', 80), PASSWORD_BCRYPT)));
But I would not consider this an issue. Users rarely create passwords
longer than 72 bytes. 72 bytes
> Please find the following resources for your references:
>
> RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023
> Discussion Thread: https://externals.io/message/121004
> Feedback by a Hashcat team member on Fediverse:
> https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075
I
Hi
On 9/22/23 10:46, Craig Francis wrote:
On 22 Sep 2023, at 08:04, Nicolas Grekas wrote:
For the record, I voted for 11 because I think it's nicer to end users (I guess
many don't know they could have a potential DoS vector via password
submissions), and also because it's going to be easy
Hi
On 9/25/23 06:20, Theodore Brown wrote:
Thanks for your work on this. I think bumping the default BCrypt cost from 10
to 11 is reasonable, as this typically adds less than 100 milliseconds
additional latency, which shouldn't be too noticeable for users logging in.
However, I am concerned
On Thu, Sep. 21, 2023 at 12:26 PM Tim Düsterhus wrote:
> I just opened the vote for the "Increasing the default BCrypt cost" RFC.
> The RFC contains a two votes, one primary vote that requires a 2/3
> majority to pass and a secondary vote deciding on the new costs with a
> simple majority. Voting
more results on ARM:
RK3399 - Cortex-A7x
Cost 10: 10.694221 total (0.106942 per hash)
Cost 11: 21.360409 total (0.213604 per hash)
Cost 12: 42.692786 total (0.426928 per hash)
RK3399 - Cortex-A5x
Cost 10: 15.146773 total (0.151468 per hash)
Cost 11: 30.272059 total (0.302721 per hash)
Cost
On 22 Sep 2023, at 08:04, Nicolas Grekas wrote:
> For the record, I voted for 11 because I think it's nicer to end users (I
> guess many don't know they could have a potential DoS vector via password
> submissions), and also because it's going to be easy to raise again in
> 8.5/9.0.
+1
I
Hi
On 9/22/23 09:04, Nicolas Grekas wrote:
For the record, I voted for 11 because I think it's nicer to end users (I
guess many don't know they could have a potential DoS vector via password
submissions), and also because it's going to be easy to raise again in
8.5/9.0.
I was wondering if you
I just opened the vote for the "Increasing the default BCrypt cost" RFC.
> The RFC contains a two votes, one primary vote that requires a 2/3
> majority to pass and a secondary vote deciding on the new costs with a
> simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC.
>
> Please find
Le 21/09/2023 à 19:26, Tim Düsterhus a écrit :
Hi
I just opened the vote for the "Increasing the default BCrypt cost" RFC.
The RFC contains a two votes, one primary vote that requires a 2/3
majority to pass and a secondary vote deciding on the new costs with a
simple majority. Voting runs 2
Hi
On 9/21/23 19:26, Tim Düsterhus wrote:
I just opened the vote for the "Increasing the default BCrypt cost" RFC.
The RFC contains a two votes, one primary vote that requires a 2/3
majority to pass and a secondary vote deciding on the new costs with a
simple majority. Voting runs 2 weeks until
Hi
I just opened the vote for the "Increasing the default BCrypt cost" RFC.
The RFC contains a two votes, one primary vote that requires a 2/3
majority to pass and a secondary vote deciding on the new costs with a
simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC.
Please find
20 matches
Mail list logo
