Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am implementing a password vault program with java. I have programmed a triple DES for encryption and a SHA256 for hashing.

My question is would it make any difference if I first hash the raw data (password) and then encrypt it, or first encrypt the data (password) then hash the encrypted data. I am mostly concerned about, would it make any serious differences between them in terms of security.


share|improve this question
But doesn't a password vault require the ability to decrypt the password? So how would hashing work? – CodesInChaos Mar 13 '13 at 12:34
I don't really know for sure, but I would posit that you should encrypt first then hash. This is because your result will be a hash, and you will need to brute force the hash (Hard because of large input), then break the key. Conversely, if you hash first, then encrypt, it will be much easier to break the encryption because the input string is so small. – JZeolla Mar 13 '13 at 12:35
You first should figure out and post what your program should do, and what security properties you want. Only then you can tell what crypto you need. – CodesInChaos Mar 13 '13 at 12:36
Well, in the program I was planning to see, has there been any changes with the password by an attacker. That is why I am using a hash – Ekin Mar 13 '13 at 12:39
Hash is irrecoverable. You can employ a combination of simple encoding/substitution which are reversible before the actual DES encryption. Leaking of sequence of these trivial steps render it useless to do it first place. – SparKot Mar 27 '13 at 12:20
up vote 13 down vote accepted

You don't want a hash; you want a MAC.

The scientific answer: you apply the MAC after encryption, not before. It is known as "encrypt-then-MAC" and it has a lot of benefits over doing things in reverse (aka "MAC-then-encrypt") or in parallel ("MAC-and-encrypt"). See this question for details.

The moral answer: don't do it. It is hard to make these things securely. You don't know enough to do it. Even people with a PhD in cryptography consider that they don't know enough to do it. When such a thing must be done, a cryptographer produces a tentative design and submits it to his peers, who scramble and try to break it for several years. Only survivors are deemed "apparently secure".

The practical answer: there are nice encryption modes which combine encryption and MAC for you; these schemes have survived the onslaught of enraged cryptographers. See GCM and EAX.

share|improve this answer
this answer is quite useful, thanks – Ekin Mar 13 '13 at 13:09

Let's take all the possible cases I can think of:

  • If the password you're referring to is the password to decrypt the vault, you probably do not want to store this on disk. There is no benefit to encrypting it, and you want to use a key derivation function such as PBKDF2 or bcrypt.
  • If the password you're talking about is one stored in the vault, hashing it will prevent you from retrieving it.
  • If you are trying to verify any cryptographic data, you don't want a plain old hash, you want a message authentication code, and you should encrypt-then-mac. A better way would be to use an authenticated encryption mode which performs this for you alongside encryption, available in all good cryptographic libraries near you.
share|improve this answer
To be more specific, the password vault will parse the encrypted data from a XML file. Therefore, the XML file will be on the local disk, not on a certain database or online. – Ekin Mar 13 '13 at 12:47

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.