7

My Question(s)

I am wondering if I have a password (long enough) and I cypher it by itself (let's ignore the salt) in this way:

cy_hash(mypassword)=cypher(text=mypassword,key=mypassword)

Then, is cy_hash as secure as md5, sha1, sha512, etc?

Also:

  • Is there any theoretical comparison between these methods?
  • Has this method ever been used in practice? If not, why?
  • Is there any research on this hash?

My research efforts

As for my research efforts, I have looked around and found the following Q&As:

but those Q&As do not answer my question. You can safely skip linking to them.

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
edwardo
  • 73
  • 1
  • 3

3 Answers3

19

There is an important misconception on your part: in general cryptographic hashes such as MD5, SHA-1 or SHA-512 should not be used to directly hash a password. A password hash or PBKDF should be used. Examples are PBKDF2, bcrypt, scrypt and Argon2. These functions also take a salt and work factor to provide additional protection.

There are a few problems with your idea:

  1. as noted in the comments, a cipher generally takes a key with one or more specific, pre-defined sizes;
  2. a cipher would output a size as large or larger than the input which would leak the password size (and require VARBINARY in databases, larger buffer allocation etc.);
  3. it is missing additional parameters such as a salt or iteration count to make it a password hash;
  4. it would have almost the same performance as just hashing the password (it would offer no advantages, in other words).

No, there is likely little to no research as it would be dismissed out of hand. There was however a password hash competition quite recently where it could have been entered (and immediately dismissed).

Note that MD5 and SHA-1 have been broken and should generally not be used anymore.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
4

No, it is not. The function of a hash is to have an irreversible function. The function of a salt is to prevent rainbow tables.

If you use you approach on a large user DB, and this DB gets out (bad enough in the salted case), people can use a rainbow table to get valid login information to your system with high probability.

Sascha
  • 148
  • 3
1

Of course it depends on the choice of cypher(), but in general, no, it's not secure. Here are some of the problems with your scheme:

  • It's too fast. We want a password hash to be slow, so offline dictionary search will take a long time. Password hashing schemes are designed to be slow (with a tuning knob that lets you control exactly how slow). For typical encryption methods, your scheme isn't slow; it'll be too fast, and that's actually a bug, not a feature.

  • Artificial length limits on the password. Your scheme doesn't allow arbitrary-length passwords; the length of the password is limited by the length of the cypher() encryption algorithm. For instance, AES128 takes a 16-byte key. That means that your scheme couldn't accept passwords longer than 16 bytes, if we used AES128 encryption as cypher(). That's generally a bad idea -- artificial restrictions on the length of the password can only harm security.

  • Not deterministic. We need password hashing to be deterministic: hash the same password twice, and we need to get the same answer both times. Most modern secure encryption algorithms are randomized (for IND-CPA security). For instance, they might use a random IV. That will be no good when we use it with your scheme. This is fixable, by eliminating all the randomness and replacing it with fixed values, but it requires modifications before we can apply your scheme.

There are other problems, like lack of a good way to provide a salt.

Overall, it means that your scheme has significant disadvantages that standard methods don't have; and it doesn't have any compensating advantages that would outweigh its disadvantages.

D.W.
  • 36,982
  • 13
  • 107
  • 196