Yes, but now you have it too complicated for 95% of the vibe coders. So they simply won't do it. Because skipping all of those steps still results in something that compiles.

They fuck up spreadsheets as well. A truckload of business-critical spreadsheets have errors in them that often go undetected for years.

It's hard enough to get actual developers to properly consider security. Not surprised at all that vibe coders don't.

Plus, of course, most of the training data is insecure to begin with.

But let them learn by fire that there's a reason actual programmers take time to ship a product, and it's not that the AI can type faster.

I'm sure they're vibe coding as fast as they can!

> Throttling is ineffective if you base it on IP address...

I didn't dictate any specific throttling algorithm. You are stabbing a strawman.

> an attacker obtaining the encrypted vault is probably not going to be able to decrypt many passwords,

That may not be how they breach them. It's an extra layer or device that may have an inadvertent security flaw. The more turtles in the stack, there more turtles there are to hack.

It will be interesting to see who gets rich after the bubble pops. Biggest Game of Financial Chicken Ever, Believe Me!

"Covfefe"

The random ones are too hard to remember, most will copy and paste. Either that, the help-desk is swamped with resets.

I'm not understanding why the traditional approach doesn't need throttling. Keep in mind a DOS attack is usually considered a smaller "sin" than a breach(es). If you allow too many retries, then the second sin is more likely. I see no third option*, it's either a DOS freeze or lots of retries.

If hackers find a design weakness in your company's preferred/required password-keeper, they can potentially hack them all. A company can allow multiple keeper brands, but then they either have to vet them all, or accept that some users will select a dodgy brand.

> I read your setup as a global throttle. If that's not what you meant...

* The best throttling and/or DOS defense strategy/algorithm is a more involve topic, but so far not a difference maker in what we are comparing.

> so now attackers can easily DoS your login system.

What keeps them for doing that with a traditional system? Even a traditional login screen should be throttled.

> Which is why you store it in a password-keeper

Another vector for hacking.

Correction: "With enough". Damn, I hope such simple typos are not a sign of Heimalzers, or whaddever itz called.

Without enough practice, many Alzheimer's patients can learn to get good enough.

The "requirements" for a secure passwords will keep trending up such that harassing users to write War and Peace to log in is a dead end.

The password server should be in a special box that throttles requests. It would have a very limited and primitive interface to the outside world; technicians would have to physically unlock it to service it. There would be a mirror server for a backup.

That way no hacker can run gajillion retries on a password without swiping the actual box.

This seems like a contradiction, I'm not following. Perhaps you mean "use" differently than I'm interpreting.

Schizophrenics are people too...including the orange guy who "sees" dog-eating Haitians tampering with voting machines using windmill radiation.