Is AES encrypting a password with itself more secure than SHA1?

Question

This isn't really a practical question, but more a question of curiosity. I heard a CS professor recommend stepping up from md5ing passwords not to SHA1, but to AES encrypting the password using itself as the key. Does anybody have any insight as to whether this is actually more or less secure?

Some thoughts on the matter:

• SHA1 is one-way, which should make it more secure than a function that preserves the data.
• On the other hand, the hacker can't possibly take advantage of AES' decryptable nature because he doesn't yet know the password.
• Unless he guesses it. But then he would be in no matter how I encrypted it.
• Since you know the AES'd password is decrypted when the decryption key matches the output, it could be bruteforced on the hacker's computer.
• But the hacker doesn't know how it's encrypted, so he wouldn't be trying that.
• But the hacker could have got the encryption code as well, in which case it's simply a question of which data takes longer to brute force.
• Most websites use md5 or sha1 (right?), so lookup tables for these hashes would be far more widespread than for the AES method. Thus making the AES method more secure.
• But if we salt both methods, they would become equally immune to lookup tables.

Some common points in the answers, and counter-points:

AES encryption is not designed to be collision resistant, and thus will probably have more collisions for the same hash string length.

If we're using a longer salt, then the encrypted password will be longer than a SHA1 hash. This may be enough to bring the collisions down to a comparable level - or maybe not.

AES encryption tells you how long the password was, within 16 bytes.

We can add to the AES method: after encrypting it, we pad or trim to a reasonable length (which is longer than SHA1's so as to avoid collisions).

Answer 1

Short answer: bad idea, don't do it.

---

Longer answer: the point of the exercise is to store something which allows the server to verify a given password, but does not allow it to rebuild the password; the latter property is desirable, so that consequences of an illegitimate read access to the server database by an attacker remain limited.

So we want a one-way deterministic transform which converts a given password into the verification value. The transform shall be:

• configurably slow, so as to thwart dictionary attacks;
• distinct for every instance, to prevent parallel dictionary attacks, including precomputed tables (that's what salts are about).

A single invocation of MD5 or SHA-1 fails on both accounts, since these functions are very fast, and not salted. Slowness can be done through nesting many invocations (thousands, possibly millions), and the salt can be injected "somewhere", although there are good and bad ways to do it. PBKDF2 is a standard transform which does just that, and it is not bad at it (although bcrypt should be somewhat preferable).

However, MD5 and SHA-1 do at least one thing right: they were designed to be one-way. That's hard to do; it is not even theoretically proven that one-way functions can really exist at all. Cryptographers around the world are currently involved in a competition to design a new, better one-way hash function.

So what your professor seems to recommend is to replace a function designed for one-wayness, with a function which was not designed for one-wayness. It does not correct anything about slowness and salting, but it removes the one good thing about MD5 and SHA-1. Moreover, AES is known to be relatively weak with regards to related-key attacks -- that's not a problem as long as AES is used for what it was meant to, i.e. encryption, but it becomes an important issue when it is subverted into a building block for a one-way hash function. It seems possible to build a secure hash function by reusing parts of the AES design, but it requires substantial reworking (see for instance Whirlpool and ECHO).

So do not use a homemade AES-based password hashing scheme; for that matter, do not use anything which is "homemade": that's a recipe for disaster. Security cannot be tested; the only known way to make a secure algorithm is to have hundreds of trained cryptographers look at it closely for a few years. You cannot do that by yourself. Even a lone cryptographer will not risk that.

Instead, use bcrypt. PBKDF2 is not bad either.

Answer 2

Most websites used md5 or sha1 (right?), so this is what a hacker would be expecting. Thus making the AES method more secure.

Even if most websites use MD5 or SHA1, switching to AES just for the reason that it's usually not used there wouldn't make it any more secure - that's just security by obscurity, which usually doesn't effectively contribute to increase security; it will be far more secure to use a good algorithm (which is well-tested for the given purpose) and document it publicly, than use an algorithm of which you can't be sure if it's good, and not say that you're using it.

At the moment I can think of the following possible disadvantages when using AES or any other encryption algorithm like this:

1. Encryption algorithms are usually not designed for avoiding collisions: As pointed out in the comments below, it might not be a problem because of the expected pseudo-random behavior of block cipher. But still, you are using an encryption algorithm for something it wasn't designed for.
2. It is imaginable that there are attacks on encryption algorithms which are far easier to do if one knows that clear text and password are actually one and the same (should the fact about the algorithm you're using somehow leak, which is not that unlikely given that it's e.g. discussed here).
3. Encryption algorithms produce data which in many cases varies with the length of the cleartext. That means, the ciphertext holds information on how long the password is. In the case of AES this is a multiple of 16 bytes as far as I can tell; hash values, on the other hand, have a fixed size (e.g. 160 bit / 20 bytes for SHA1); meaning that a potential hacker has a chance of getting more information out of a encrypted text than out of a hash value.
4. In cryptographics it's usually always less secure too cook up something by yourself (which is subsequently probably also only used by you) than using something which is well tested and out in the community for a long time already (meaning it had time to be thoroughly inspected by a number of cryptanalysts).
5. You want to make sure your password hashing algorithm is slow, so that potential attackers are hindered to brute-force their way into your system. One way to achieve this is for example to iteratively perform the hashing in multiple rounds, as for example PKBDF2 does. For more details, see http://security.blogoverflow.com/2013/09/about-secure-password-hashing/

Answer 3

One immediate problem I see with this approach is the fixed key length of AES. Using AES-128, one would be restricted to 16 bytes of the password. What about longer passwords, or, long passphrases?

To accommodate for any password length you would need a hash function, so back to the initial point.

Note that there are well-studied and secure* ways of turning a block-cipher into a hash function, so called PGV modes like Davies-Meyer, Matyas-Meyer-Oseas or Miyaguchi-Preneel.

(*) For an appropriate definition of "secure".

Answer 4

However, consider this:

I break into your site and get enough access to notice that you have AES keys configured for your system, only thing that looks "encrypted" is yours passwords... guess what I'm going to do.

I would keep them hashed, leaves a lot less room for easily scraping your entire password database.

On top of that, as a site owner, I DON'T want the ability to decrypt my user's passwords in the first place, otherwise the option to "recover passwords" becomes a possible feature that higher ups can ask for, and technically, we can do it because the underlying system is built using an encryption system instead of a hashing system (a lame reason but software developers deal with requests like these).

Mainly: When security is concerned, don't try to do something wacky and out of the box, you'll likely write yourself a huge security hole because you wont be able to put the amount of research a team of people working on an algorithm for a specific purpose would have to.

Answer 5

The correct answer is: It does not really matter at all.

In the case of passwords, the only practical attack is to try out a list of passwords until you find the right one by brute force. No one will try to attack SHA1 nor AES directly to do that. Even in the current point of research, attacking SHA1 would be ten thousand times easier than AES, both are still completely impossible (for reversing password hashes because collisions do not matter here). And as a researcher finds another way to attack the other algorithm, the odds might be reversed next year.

What might matter is how fast you derive your hash / encrypt your password. But if e.g. SHA1 is faster and you want it to be slower (to fend off brute-force attacks), you can just hash multiple times.

What a hacker "expects" is not that relevant, making something "unexpected" is just obscurity. It's like saying "I reverse all the password letters, now it's more secure". It won't be. If the hacker can access your password database, how can you be sure he doesn't have access to your password hash derivation function?

One flaw when "encrypting a password with itself": The length of the ciphertext might give the attacker a clue about the length of the password. That's awful.

In any case, you should salt the password, preferably with something unique to the user.

Answer 6

There are MACs (Message Authentication Codes) constructed from block ciphers; the best known is probably CBC-MAC. It has issues compared to a hash-mac, notably:

Given a secure block cipher, CBC-MAC is secure for fixed-length messages. However, by itself, it is not secure for variable-length messages. An attacker who knows the correct message-tag (i.e. CBC-MAC) pairs (m, t) and (m', t') can generate a third message m'' whose CBC-MAC will also be t'.

[...]

This problem cannot be solved by adding a message-size block (e.g., with Merkle-Damgård strengthening) and thus it is recommended to use a different mode of operation, for example, CMAC to protect integrity of variable-length messages.

The shorter answer: The security of a MAC built from a block cipher depends on how you construct it. A naive construction will almost certainly have significant flaws.

Answer 7

The fact that you have designed an unusual algorithm does not make it secure. "self made" algorithms are dangerous, because nobody has carried out cryptographic analysis of them.

As @Thomas Pornin wrote above, AES was not designed to be collision resistant. Besides, AES is relatively fast, which simplifies attacks.

SHA1 is designed be collision resistant, but SHA1 is also designed to be very fast, because its purpose is to generate hashes of big volumes of data or files in a short time. Its purpose is not to prevent attacks on hashed passwords.

If you want to generate a password hash that is resistant to different kinds of attacks, consider password stretching. Depending on your technology stack and available libraries consider bcrypt, scrypt, argon2.

Answer 8

Reading all the answers, the only strong claims I found against this idea are as follows:

• Encryption methods are not designed to be collision resistant.
• Despite encryption methods, hash methods are designed to be slow and take RAM (maybe not much applicable to SHA1).
• Hashing methods can handle salt.

You can still challenge each one or find a solution to get around them. But, that is for now as it is.

And of course, we look at the issue theoretically. I hope you are not going to apply these none-researched ideas on your website.