2

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?

J. Doe
  • 125
  • 4
  • @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 08 '18 at 00: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 08 '18 at 02: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?](https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own). – Steffen Ullrich Jun 08 '18 at 04: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 08 '18 at 04: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. https://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 08 '18 at 04:44

2 Answers2

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.

hft
  • 4,940
  • 17
  • 32
  • 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 08 '18 at 03:34
  • Glad to hear it! – hft Jun 09 '18 at 04: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.

vrtjason
  • 1,085
  • 9
  • 10
  • 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 08 '18 at 00: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 08 '18 at 00:14
  • So it basically is for brute forces, in a way. – J. Doe Jun 08 '18 at 00:20