Encrypting user-specific hash? When a user registers, a random personal salt is generated. Then hashing is done like so:

hash(hash(USERNAME . PEPPER . PASSWORD) . PERSONALSALT)


Then the personal salt is encrypted using password as key and placed in the database along with hash. When user attempts to log in, personal salt is decrypted, and used to hash and compare. Is this a good idea? The hashing function is SHA-256 iterated roughly half a million times depending on sever specs.

Yes I am aware that "rolling your own encryption" is a mortal sin. I am just wondering hypothetically if it would function. I would never use something made sketchily in a production environment.
No it is not a good idea as a password cannot be directly used as a key. You would need a PBKDF (password based key derivation function) with a salt and work factor to create a reasonably secure key out of a password. But that leaves us with a problem: you are trying to create exactly such a function - password hashes and PBKDF's are largely synonymous.

If you do not derive a key correctly then the decryption may leak information by which you can retrieve your password even without going through the iterations. If padding oracles apply during decryption in your scheme then the resulting implementation would be very weak, to name just one issue.

The salt does not require confidentiality in PBKDF schemes, so encrypting it should not disallow any attack.