n0rdy

That would work from the technical point of view, I do agree.

On the other hand, how would we make "lazy" people use those? And ensure that won't reuse the same password on some vibe coded forum that will store them in the plain text and get hacked in a few weeks =)

That's why I mentioned that mindset shift as the prerequisite.

Sorry, I might be too young to remember those times. Can you tell me more, please? I'm genuinely curious.

Because from the sound of that, it feels that it would patch the `123456` problem, but opens up a new vulnerability - the password is known / being sent through / printed, so it can be leaked from that source.

Unfortunately, the humans' laziness (or lack of long-term thinking) was, is and will be a bottleneck.

If we technically restrict the minimum length to, let's say, 12 chars, the default passwords will be smth like `123456789012`. If we add the requirement to have 1 letter, at least, the passwords will be `12345678901a`. If we require a special character, we'll get smth like `1234567890a!`.

I believe the issue is not technical, and it's not about the one particular guy. It is about accountability and understanding the impact and responsibility of the "I don't care"/"whatever"/"ship fast" mindsets.

We need a proper social agreement for that, as this goes far beyond the passwords, especially these days when the quantity and speed are valued over quality.

Flipping through the source code is like a time machine tour of tech's evolution over the past 50 years. It made me wonder: will our 2025 code look as ancient by 2075?

And, btw, great infographics within the post.

I wrote this post in December 2023, and rediscovered it today. Seems like it hasn't dated yet, even though the AI landscape evolved a lot in the dev tooling space.

Yes, indeed, in this particular case it is exactly as you said. However, I've seen this in the tech industry, that's a surprising bit for me

> How does a company whose only job is security screw that up so badly?

While I don't have any answers to this, I've realized that it's an ideal showcase of why fuzzy testing is useful.

Author here: thanks for reading the post.

It's great to hear that Zig covered both cases. However, I'd still prefer the opposite behavior: a safe (without truncation) default `bcrypt()` and the unsafe function with the explicit name `bcryptWithTruncation()`.

My opinion is based on the assumption that the majority of the users will go with the `bcrypt()` option. Having AI "helpers" might make this statistic even worse.

Do you happen to know Zig team's reasoning behind this design choice? I'm really curious.