1

I am curious how secure the following approach is for authentication:

  • By every account I encrypt data with known structure using a symmetric algorithm (e.g. AES or twofish) with a password derived key. The data can be for example a JSON encoded object an XML or anything else, which is easy to verify. I use different IVs by every account, a secure mode of operation, block encryption, etc...
  • By login I try to decrypt the cipher text with a key derived from the given password.
  • If the resulting data has the proper structure, then the password was ok and the user is authenticated. Otherwise the password was wrong and the login attempt failed.

Is there any drawback by this approach compared to the usual password salting and hashing?

inf3rno
  • 487
  • 1
  • 7
  • 19

2 Answers2

3

Yes, there is a drawback, even if it’s „only“ a practical one (yet I perceive the collision rate (wrong password derived a key that decrypts to something following the syntax you expect) to be higher in your scheme, but I didn’t to the maths, because the other drawback is prevalent).

There are way more moving parts in your scheme than in the usual password hashing. This means more things can go wrong, especially if you implement this yourself. Using a hash function is easy in comparison to using a block cipher.

Implementations and examples on secure hashing for passwords are easily available while an implementation of your scheme would be somewhat special, offering way more pitfalls in implementation.

Additionally, this would allow attackers that have the database to crack the users passwords maybe as easy. Depending on which hash function and salting you use, AES, that is mostly implemented in hardware, is fast in comparison - and only one block would be a good indicator of correct decryption.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
2

Is there any drawback by this approach compared to the usual password salting and hashing?

There is usually no reason to invent your own password hashing method as long as the existing ones would fit your purpose. It is hard to get it better compared to picking a known strong and established method. But it is easy to do it wrong.

The strength of current password hashing methods comes from multiple aspects:

  • irreversible function to make computing input from output is impossible
    This is done by using cryptographic strong hash functions.
  • slow validation of a single password too slow down brute-force attacks
    This is done by creating slow hash functions and even looks at keeping these hash functions slow even if the attacker has build hardware specifically to address the speed problem.
  • multiple outputs (storage) for the same input (password) to make pre-computing infeasible
    This is done by using a random salt for each hashing. The salts are drawn randomly from a large enough sets so that pre-computing and storing the results of all possible inputs gets infeasible in time and memory.

Let's see how your idea compares with this established approach:

  • irreversibility
    This is probably given as long as your key derivation function (to get encryption key from password) provides this property. Only, there is nothing known about this function so I assume that you did not consider that this function might need to have special properties.
  • slow validation to slow down brute-force
    No aspect of your algorithm cares about slowing down brute-force and no aspect is inherently slow. This again might be done inside the key derivation function but again you don't require a specifically constructed function for this.
  • multiple outputs (storage) for the same input (password)
    This is probably guaranteed by having a random IV for each encryption.

In summary I would say that the security of your approach depends on the choice of key derivation function, i.e. the KDF being a slow and one-way hash. Since you did not require your KDF to behave that way I would consider your idea a bad idea. Even if you require the KDF to be strong and slow enough there might be other problems of you algorithm which I did not recognize in the short time.

Again, don't invent your own if a working method exist which solves your problem. Usually it only gets worse, not better.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Afaik. AES and twofish are not vulnerable to known plain text attacks, so it would be hard to reverse the process and find out what the password was even if you know the encrypted data. Am I missing something about this? If this is true, then there is no need to slow down brute force, since it would require a few billion years even with super computers. I understand that many things depend on the implementation, I was just curious, whether there is a flaw in the general approach. I understand that without proper implementation it will fail just as hashing with md5... – inf3rno Nov 21 '17 at 07:12
  • Just a reference for the known plaintext attack: https://crypto.stackexchange.com/a/1515/52693 – inf3rno Nov 21 '17 at 07:17
  • Hmm I think I understand now. So if the key is not 128+bit long or easy to create based on a dictionary, then it might be susceptible against these known plaintext attacks. Thanks for your input! – inf3rno Nov 21 '17 at 07:28
  • Is using PBKDF2 would solve these problems? – inf3rno Nov 21 '17 at 07:36
  • @inf3rno: First, known plain text attack is not about extracting the plain text as you would need for your arguments about reversing the process but about extracting the encryption key. Also, brute-forcing passwords works not by trying to reverse the process (i.e computing possible input from output) but by checking if a specific input results in the expected output. – Steffen Ullrich Nov 21 '17 at 07:58
  • @inf3rno: *"Is using PBKDF2 would solve these problems?"* - Using an established method for storing passwords (like PBKDF2, but there are better) __instead__ of using your process will solve the problem. But if you ask if using PBKDF2 as a KDF in your process would solve the problem also - I'm not sure about this. It might be that the rest of your algorithm might introduce some new weaknesses but I'm not sure. But again, unless there is a very important reason to do different you should keep with established, well researched and known to be good algorithms instead of inventing your own. – Steffen Ullrich Nov 21 '17 at 08:02
  • Yes, I know that known plaintext attacks are about finding the key. I just thought they use an inverse function to count it instead of trying out every possible keys. To harden the latter you really need a good KDF, you are absolutely right. If there is no obvious weakness in the approach that is good enough for my current goals. Thanks for your answer! – inf3rno Nov 21 '17 at 09:35
  • @inf3rno: That I don't see any obvious weakness in the current approach does not mean that somebody with more knowledge or more time would see one. While your idea might be fine for some play project where you want to just try out different ideas I would strongly suggest to not use it in any kind of serious stuff. It is in no way better than existing methods but introduces additional complexity and maybe also weaknesses this way. – Steffen Ullrich Nov 21 '17 at 10:31
  • Thanks Steffen! I'll try it out by a hobbi project now, so nothing serious. :-) – inf3rno Nov 21 '17 at 11:01