If I implement a function which hashes the first half of my password with MD5 and the second half with SHA-2 and MD5, is there a security issue when I put these two hashes together to create a 64 character string?

Password: "test123"

first_half: md5(test+salt1);
second_half: sha2(md5(123)+salt2);
hash = first_half + second_half 

I would like to use something like this to stretch the hash, so that the attackers will not know what kind of hash I used. So standard rainbow tables will be useless. Also, there will be no standard MD5 collisions, because it has more characters. Am I right?

  • 9
    Same answer as always, use a salt and a specialized function, such as PBKDF2, bcrypt or scrypt. Don't invent your own silly schemes, unless you have a good reason and you know what you're doing. Commented Nov 15, 2012 at 11:10
  • Rainbow tables and collisions aren't an issue if you use bcrypt, scrypt or PBKDF2. It sounds like you might want to read about "pepper" too (but it's debatable if it's worth the effort): security.stackexchange.com/questions/3272/… Commented Nov 15, 2012 at 18:00

3 Answers 3


No. It'd be trivial for them to just take each part and bruteforce it, even for strong passwords. You're falling into the same problem as NTLM did in the early days, where a long password ends up being two really short passwords which are easy to bruteforce independently.

Instead of having to crack one 10 character password (assuming a-z 0-9 that's a keyspace of 3.656×1013) they only have to crack two 5 character passwords (keyspace of 120,932,352 for the same password) making the problem several orders of magnitude easier for them.

If you're looking to hash passwords, use a strong key derivation algorithm such as bcrypt or PBKDF2.

I recommend having a read through these two questions over at IT Security:


Splitting the password is bad.

Designing your own password hashing mechanism is not good, either. It is fine for learning purposes, but for production, this is a no-go, because you cannot know whether you did things right or not. It is a generic and all-encompassing flaw of homemade cryptography. Of all cryptography, really; but, at least, with public standards like bcrypt, you benefit from the review of many eyes during many years.

You say that the attackers "will not know the kind of hash you used". That's wrong; they already know it, probably better than you. First of all, they have Internet access, so they can read this very question that you ask on StackExchange. Also, the hashing method exists as source code somewhere, and some executable script or binary on your server, so it cannot be really secret. In particular, you want to hash the passwords before storing them because you envision an attacker who could obtain an illegal read-only access to the data stored by the server (otherwise you would not need to hash them); it is very conceivable that such an attacker will also get read-only access to the server code itself, and thus gains knowledge of the hashing method you use.

Last but not least, you cannot know how much your hash algorithm is secret. Much of security is about quantifying and measuring. With a password, you can estimate the entropy, depending on the generation mechanism; same for any secret key: keys live in a space of a size which can be assessed through mathematics. But the secrecy of an algorithm, which exists in various places, including source code, executables, possibly printed sheets, backups, and the brain of some developers ? How much secret can that be ?

Kerckhoff explained it quite clearly more than one century ago: you shall not consider your system as secret. Keys (and passwords, which are just a kind of key) are designed to concentrate the secrecy, while the rest of the algorithm must be considered as public -- because, most of the time, it is public knowledge.


In practice I've seen this done even for users in db's for instance to obscure the user info of minors, even for their login name. If I remember right it was something like [email protected] the same could be used for passwords and I suppose if you were concerned w/ keeping those strings in the db you might could do an xor on them a few times (so it's a bit faster to calculate then 100 or 1000x) and be 'not as' easily reversible... e.g.

(Sha1 xor Sha2 xor md5) * CRC32 

The CRC32 is just for fun, but you could use a shift left or right before the bit operators if you fancied it.

Hope that helps!

  • 1
    This is a bad idea. Arbitrarily sticking stuff together like this does not improve security, and may have a serious negative impact. Furthermore, recommending CRC32 for password hashing is beyond terrible advice.
    – Polynomial
    Commented Nov 15, 2012 at 23:03
  • The question is how to make a hash that cant be looked up via standard tables. I stand by my answer and believe it would do just that. Commented Nov 17, 2012 at 7:04
  • Yes, and so would ROT13. Doesn't mean it's secure.
    – Polynomial
    Commented Nov 17, 2012 at 13:19
  • Agree, as I said you could shift left or right to do the same thing which is essentially a rot13.. I never contended that this is in any way secure, just that it was on point. If calculating a bunch of MD5's was too expensive (which time to calculate hash is part of security), you could reduce the workload via a simple method. Commented Nov 17, 2012 at 17:35

You must log in to answer this question.