Password derived hash to encrypt known plaintext as password check The title sounds way too adventurous for what it actually is. I am currently building a system which features some encryption. There is already a system in place, which is built after that scheme if somebody is interested in more context: https://stackoverflow.com/a/44925718/5395110.

As a next step I have to plan user authentication (typical username-password-login). First I thought of a standard password-hash approach using Argon2i hashing. That sounded reasonable but then I realized that with enough bad luck I would essentially give the attacker a free pass to the data in combination with the already built system. To prevent that I thought of integrating password checking into the existing system and get rid of any hash stored as plaintext.

What I came up with:


User inputs password and sends it to the server
The password gets hashed with Argon2i => hashed password
Hashed password is used to decrypt a AES-256-GCM-secured ciphertext 
If the ciphertext can be decrypted and is equal to a known static plaintext then the decryption was successful and the password is valid


So my question: Is a password checking system that uses a password-derived key to decrypt a authenticated block cipher to determine validity a reasonable alternative to just saving the hash?

The advantages are that there is no hash which can be extracted so an attacker would have to first find the key to the AES-container and afterwards find the plaintext to an Argon2i hash which seems like a very unrealistic task.

The bad feeling I have with this method is that it would probably work but completely miss the point of a authenticated block cipher since what I'm essentially doing is generating a HMAC of the hashed password(secret) and the known plaintext reference password(message) in a weird and unnecessary complicated way.
To be entirely honest the Idea is pretty intresting but wouldn't help a lot. AES is, mainly because it's widely used, a pretty cheap thing to do, so there's basically just one step more after hashing, so it wouldnt make a lot of a difference in that part. but one thing that I think may be intresting would be (but for a different reason):

Not encrypting a static String, but rather use the hash to create or encrypt a random Private Key generated while the user is signing up, while keeping the Pubkey readable and offer it to the user.

If you now use that specific key to sign something (similar to a canary report) and the user can check that it was signed with his key, then he can be relatively sure that for example no password reset happened because one cant reset the password without resetting the keys.