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.