Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Jan 8 '12 at 5:09

This question came from our site for professional and enthusiast programmers.

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 '12 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 '12 at 8:41
4  
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 '12 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 '12 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) –  CodesInChaos Jan 8 '12 at 20:42

6 Answers 6

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 three 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, this won't a problem, because of the expected pseudo-random behavior of block ciphers (thanks to Kosta and Krystian); so, in short, if it's a good encryption algorithm, there won't be more collisions than when using a good hashing algorithm.
  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. Even if all the above points should not apply, 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).

When trying to increase security for the given problem, I'd suggest to rather switch from MD5 or SHA-1 to the next generation hashing algorithms (SHA-2 or the winner of the ongoing NIST hash function competition) - and of course salting the hashes - than using any self-devised method.

share|improve this answer
    
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 '12 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 '12 at 9:15
    
@skier88: as for the length: might be a theoretical point since it's rather hard to brute-force passwords of lengths over 16 bytes anyway, but it's certainly an advantage to know that the password is between 16 and 32 bytes long than to know nothing about the password at all –  nyarlathotep Jan 4 '12 at 9:21
    
Actually, I just realized this. You could easily pad or trim the resulting AES - they would know what you've done if they got your code, but they still wouldn't know how long the password was. But I'm guessing it would still be more prone to collisions. –  skier88 Jan 4 '12 at 9:47
2  
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 '12 at 10:34

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.

share|improve this answer
    
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 '12 at 9:28
    
Don't know why I typed "common lengths". Make that indicative lengths. –  skier88 Jan 4 '12 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 '12 at 9:50

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

share|improve this answer
    
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 '12 at 10:02
    
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 '12 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 '12 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 '12 at 10:25

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.

share|improve this answer
    
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 '12 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. –  Nick Johnson Jan 5 '12 at 2:50
    
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 '12 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'. –  Nick Johnson Jan 5 '12 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 '12 at 3:28

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.

share|improve this answer

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 technologically, 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.