Key stretching a hash

Question

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?

Example:
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?

Answer 1

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×10¹³) 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:

• Do any security experts recommend bcrypt for password storage?
• How to store salt? (contains a detailed explanation of why key derivation and salting is necessary)

Answer 2

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.

Answer 3

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!