Password storage is not where to be creative. The safe path is well established.
The first rule
Never store passwords with a plain fast hash (MD5, SHA-1, SHA-256) or with reversible encryption. A fast hash is exactly what brute force beats, and reversible encryption means a stolen key exposes every password.
Pick an algorithm
In order of preference: Argon2id as the default, then scrypt, then bcrypt, and PBKDF2 only where FIPS compliance forces it. All of them salt automatically or must be given a unique salt.
Set the parameters
Tune the work factor so a single hash takes a chosen wall-clock time on your hardware, then raise it as hardware improves. OWASP publishes current starting points, for example Argon2id memory and iteration settings and bcrypt cost factors.
Salt, and optionally pepper
Use a unique random salt per password; the libraries handle this. You may add a server-side secret, a pepper, kept out of the database, so a database-only leak is not enough.
Favor length over rules
Allow long passphrases, screen new passwords against known-breached lists as NIST recommends, and avoid composition rules that hurt usability without adding entropy.
Migrating off a weak scheme
When moving away from a fast hash, either rehash each password on next login or wrap the old hash inside the new KDF, and never keep the fast-hash version around.