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).

  • 3
    I don't think if the function is one-way it is more secure than a non-one-way function. They are two different things..
    – duedl0r
    Jan 4, 2012 at 8:38
  • Well, I figured it was only less secure if there was some way of guessing or brute forcing the decryption key, but bullet 5 eliminates that ...
    – skier88
    Jan 4, 2012 at 8:41
  • 6
    I wouldn't consider things being 'unexpected' to carry any weight in a 'how secure is this' question. I also much prefer to leave crypto to the people who understand it - it's way too easy to make mistakes
    – Frederick Cheung
    Jan 4, 2012 at 8:47
  • Heh ... I hope there are at least a few people who don't think that way about crypto. Also, I think I was unclear in the last two bullets - question edited.
    – skier88
    Jan 4, 2012 at 8:55
  • 1
    The hash function itself doesn't matter much as long as it's decent. It's much more important to use it correctly(a salt, and a slow scheme such as PBKDF2) Jan 8, 2012 at 20:42

8 Answers 8


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.

  • 2
    Using AES to encrypt a password with the password as the key seems as much a one way function as using SHA1 to hash it. The only difference is that it was not designed for it like you said.
    – Gudradain
    Dec 14, 2015 at 14:41
  • I agree with Gudradain. More so, bcrypt, for example, was designed to be one-way and is based on encrypting a known text with the password (in multiple rounds).
    – Volker
    Dec 14, 2015 at 15:57

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/
  • You make very good points. However, this makes me wonder - if the average password is >20 characters then the AES method would, on average, produce longer encrypted passwords. Would this be enough to counteract your first point? (the average user password is certainly less than 20 characters, but let's assume we're salting it, or something else, for a moment)
    – skier88
    Jan 4, 2012 at 9:10
  • As for your edit, see bullet 6. Even if the hacker knows exactly how the password was encoded, I'm pretty sure they would still have to brute force it.
    – skier88
    Jan 4, 2012 at 9:15
  • 4
    I think point 1. is not a problem here. If such collisions would appear (more often than the theoretical bound), it would mean the block cipher doesn't have the expected pseudo-random behavior, rendering it effectively broken by modern standards. So this shouldn't happen to any currently used block cipher, in particular AES.
    – Krystian
    Jan 4, 2012 at 10:34
  • 1
    @LucasKauffman right, recommending a just-devised hashing method actually goes against my other advice of using well-tested algorithms - or are there specific other concerns against using keccak?
    – codeling
    Aug 17, 2013 at 13:33
  • 1
    Speed, keccak is designed to be very fast, which you want to avoid for password hashing. Aug 17, 2013 at 13:37

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".

  • I hadn't thought of that, but would it really make it less secure? And would you really need to hash it and not just truncate it?
    – skier88
    Jan 4, 2012 at 10:02
  • 1
    Yes, if you truncate, you loose part of the strength of the password. E.g. brute force dictionary search attacker knows your password is at most 16 characters.
    – Krystian
    Jan 4, 2012 at 10:15
  • Right, but 16 hashed characters won't be any more secure ... I think. (and we're talking trunctating just for the key, not what it hashes, which is the original password + a salt)
    – skier88
    Jan 4, 2012 at 10:19
  • Yes, the difference is only for passwords longer than 16 characters. Yes, hashing shorter passwords doesn't make it any more secure.
    – Krystian
    Jan 4, 2012 at 10:25

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.


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.

  • 1
    I can see you put a lot of effort into that answer because you haven't seen my edits yet ;) . But seriously, thanks, you make good points. See the comments on nyarlathotep's answer for a sort of counterpoint, though I think that the combination of collisions and common lengths will settle it.
    – skier88
    Jan 4, 2012 at 9:28
  • Don't know why I typed "common lengths". Make that indicative lengths.
    – skier88
    Jan 4, 2012 at 9:34
  • While I typed my answer, the internet went down and it took a couple of minutes to get up again. I should have re-read the question maybe :)
    – Kosta
    Jan 4, 2012 at 9:50

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.

  • Thank you for the reply, but I'm a little lost (as you can probably tell, I don't know much about cryptography). Why are MACs generated? And how do they affect the process of comparing an input password to stored cyphertext?
    – skier88
    Jan 5, 2012 at 1:37
  • @skier88 A MAC is a Message Authentication Code, and it's a common way to use a hash. Hashing passwords is slightly different, but similar considerations apply. My main point was to illustrate that building your own cryptosystems, even when seemingly safe, can have surprising undesired side-effects - so you should stick to primitives and systems that have been shown to be secure. Jan 5, 2012 at 2:50
  • 1
    Thanks, I do understand your main point, but I also want to learn a little terminology. So I understand now that MACs are an application of hashes, but, in the quotes text, what are the "tags" in the "message-tag pairs"?
    – skier88
    Jan 5, 2012 at 3:07
  • @skier88 In this context, the 'tag' is the output of the CBC-MAC - see the Wikipedia article for more details. If it were a hashing function, it'd be the 'hash' instead of the 'tag'. Jan 5, 2012 at 3:12
  • Ah, ok, thanks. So it seems CBC-MAC is not directly applicable to the question, but rather an example of why you have to be careful. Then again, that's why I posted this question - in the hopes that somebody could conclusively analyze this method.
    – skier88
    Jan 5, 2012 at 3:28

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.


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.

You must log in to answer this question.