2

This question already has an answer here:

I was thinking about alternatives to hashes for storing passwords, and I was wondering if there was any huge security flaw with one I came up with.

If, when the user creates their account, their password is used as a key to encrypt itself and stored that way, you could validate logins by decrypting the stored password with the given password and checking if they match.

Is there any inherent theoretical problem with this idea, assuming the encryption is immune to such things as collisions and related-key attacks?

marked as duplicate by AndrolGenhald, Conor Mancone, forest, Steffen Ullrich, symcbean Jun 8 '18 at 11:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @AndrolGenhald that one's specifically about AES encryption, and the answers reflect that. It answers the question of using AES-encryption, but not encryption in general. – J. Doe Jun 8 '18 at 0:22
  • 1
    The answer that @AndrolGenhald linked to does actually cover the general case, so I agree that the question is a duplicate. Encryption lacks both one-wayness and slowness, which are the crucial properties of password hashing. A simple dictionary attack would "crack" most of the passwords very quickly. Don't do this. Please read Pornin's answer more closely to understand why. – Royce Williams Jun 8 '18 at 2:14
  • 1
    Before designing alternatives to existing algorithms you should state why you need such self-made alternative in the first place, i.e. what of your requirements are not handled by current algorithms. If you still need to design your own system you should understand what current algorithms protect against and make sure that your algorithm does too or that these dangers don't exist in your specific use case. See also Why shouldn't we roll our own?. – Steffen Ullrich Jun 8 '18 at 4:04
  • @SteffenUllrich I don't need it. That's why I posted it on here. I was just curious why this wasn't used and couldn't find anything my self. – J. Doe Jun 8 '18 at 4:15
  • I understand the theoretical curiosity. :) A Google search for "Why should passwords be hashed instead of encrypted" yields many solid explanations - many of which are on Stack Overflow. stackoverflow.com/questions/326699 is a notable example, but the one that @AndrolGenhald linked to is from Pornin, who is an actual cryptographer, so his answer is one of the best. – Royce Williams Jun 8 '18 at 4:44
1

Is there any inherent theoretical problem with this idea, assuming the encryption is immune to such things as collisions and related-key attacks?

Yes, there is a problem with this idea even given your assumptions.

Just use bcrypt for god's sake!

Some problems: The way you have stated your encryption "solution" seems to imply that you are just using a single key and no random IV or anything like that. In that case you are vulnerable to dictionary and other brute force attacks (you are still vulnerable even with a salt since the "hash" is likely fast). Also, with nothing to act as a "salt" you will be "hashing" the same password to the same "hash" each time, which is also bad.

  • 1
    The reason I'm not just using BCrypt is because this is hypothetical, BTW. I would never actually use my own, untested solution for something like this. :) – J. Doe Jun 8 '18 at 3:34
  • Glad to hear it! – hft Jun 9 '18 at 4:09
0

You still have to make it computationally expensive like it would be in a slow hash algo like BCrypt or SCrypt. You can use a KDF with a fine tuned quantity of iterations to achieve the level of expense that your users will tolerate without noticing a performance lag.

Keep in mind that whatever is encrypted by the user's password is only ciphertext to you, so maybe of limited use.

  • Sorry for the most likely noob question, but why must it be computationally expensive? Do you insinuate that it must be complex, or is that to avoid brute forces, or?... – J. Doe Jun 8 '18 at 0:03
  • Is because your database will probably be leaked online, and you want anyone trying to decrypt the database to have a lot of effort. – ThoriumBR Jun 8 '18 at 0:14
  • So it basically is for brute forces, in a way. – J. Doe Jun 8 '18 at 0:20

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