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:

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:

  1. User inputs password and sends it to the server
  2. The password gets hashed with Argon2i => hashed password
  3. Hashed password is used to decrypt a AES-256-GCM-secured ciphertext
  4. 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.

  • Why do you actually use a master password and not simply a high-entropy random secret here (which you can print as base64 or hex if humans rarely need to interact)? – SEJPM Jul 12 '17 at 18:40
  • I'm also confused what you hope to gain from this plaintext comparison that you don't already have through the authentication tag? – SEJPM Jul 12 '17 at 18:42
  • @SEJPM The term "master password" may be misleading. I'm aware that this "master password" is never read by a human that's why it is a random 256 bit key. It's not a stupid human generated string. And the plaintext check is not (realistically) necessary but I included it in the specs anyway as it is the final assertion since a tag might not catch a wrong password in every case in the edgiest of all cases. – SkryptX Jul 12 '17 at 18:49
  • If all users passwords can derive / decrypt the master key doesn't this mean that the master key is only as safe as the weakest user password? This seems like an issue. – puzzlepalace Jul 12 '17 at 19:07
  • This is actually an issue as well as having up to 30 possible passwords that a bruteforce attack can hit, but it is the safest it can get because it is a web application and I have no control over the devices accessing it. Except I'm missing something. I'm open for additional input and ideas to make the system better. – SkryptX Jul 12 '17 at 19:29

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.

  • 1
    Yes it probably doesn't add much more security to the hashing than factor two for bruteforcing. Your other suggestion is interesting indeed. I will consider that for a future release. This seems like a nice addition with a lot of benefits for data integrity and traceability since digital document are a core part of the application. – SkryptX Jul 10 at 19:35
  • probably it wouldnt even be factor 2, when you are using something like argon2 to hash which is deliberately slow, in comparison to things like AES, which instead is made to be fast. especially with AES-NI, your decryption is a matter of milli- if not nanoseconds, basically only adding not really much to Argon2 – My1 Jul 11 at 7:27

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.