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.

if I implement an function which hashes the first half of my password with MD5 and the second half with SHA2 and MD5. Is there a security issue when I put these two hashes together to 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, and 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 kollisions because it has more characters. Am I right?

share|improve this question
7  
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. –  CodesInChaos Nov 15 '12 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/… –  Brendan Long Nov 15 '12 at 18:00
add comment

migrated from stackoverflow.com Nov 15 '12 at 14:17

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

3 Answers

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 Sha1+md5+crc@domain.com 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!

share|improve this answer
    
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 Nov 15 '12 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. –  Jeremy Adsitt Nov 17 '12 at 7:04
    
Yes, and so would ROT13. Doesn't mean it's secure. –  Polynomial Nov 17 '12 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. –  Jeremy Adsitt Nov 17 '12 at 17:35
add comment

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:

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

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