feat(crypto): use passwap for machine and app secrets

[muhlemmer]

This change introduces the use of passwap for secrets or machine users (client credentials), OIDC and API applications.
Similar to user passwords, hash configuration can now be updated in zitadel's yaml config and secrets get re-hashed when the first next verification succeeds.

Config changes

The SecretGenerators.PasswordSaltCost options are removed. These were previously set to 14 as a default. If users had custom values for this setting, it will now be ignored.

There is a new config option SystemDefaults.SecretHasher which carries passwap related config in the same way we do for human user passwords. If users wish to retain their custom bcrypt cost, SystemDefaults.SecretHasher.Hasher.Cost must be set accordingly. The new default cost is 4, which is the minimum required by the bcrypt package.

4 is actually a more than sufficient value. With the defaults of digits, lower and upper case letters, there are 64^62 possible values.
Benchmarking bcrypt on my laptop at cost 4, does around 1275 ops/second. It would take 7.5e108 seconds to go through all possibilities.
Adding the fact that these are not user passwords and the ability to brute-force the hashed secrets from the database has no value for an attacker, should they get leaked.

As this feature rehashes on config change, expect all machine user and application secrets to get a hash.updated event if no action is taken. This is fine. As the default cost is significantly lowered, there shouldn't be much overhead.

Refactorings

Crypto interface

The CryptoCode interfaces have changed into EncryptedCode interfaces. There is no longer a combined interface for encrypted and hashed codes. "old style" for generating and verifying codes has been preserved for encrypted codes, such as email, sms codes and many more. The Hashed Code generator is completely separated from this interface now.,

Generators

The generators for hashed codes are now moved completely into the command package. Previously the generator was obtained from the query package and passed into command.

Closes #6540

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• No debug or dead code
• My code has no repetitions
• Critical parts are tested automatically
• Where possible E2E tests are implemented
• Documentation/examples are up-to-date
• All non-functional requirements are met
• Functionality of the acceptance criteria is checked manually on the dev system.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 5, 2024 9:35am

[github-actions]

🎉 This PR is included in version 2.50.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀