Why improvising your own Hash function out of existing hash functions is so bad

George Powell
  • Why improvising your own Hash function out of existing hash functions is so bad George Powell

    I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes.

    After reading that cooking up your own password hash out of existing hashing functions is dangerous over and over again I still don't understand the logic. Here are some examples:

    • md5(md5(salt) + bcrypt(password))
    • scrypt(bcrypt(password + salt))
    • sha1(md5(scrypt(password + md5(salt))))

    The typical arguments against these go as follows:

    You're not a cryptographer! You've got no idea if these hashes are more secure. Leave it to the experts who know what they're doing. These add no extra security.

    Granted they don't improve the function as a hash (i.e. make it harder to reverse or find collisions etc.), but surely surely they don't make it worse as a hash? If they did then hackers would be able to re-hash standardly hashed passwords into these wacky hashes as they see fit and weaken the hash? I don't buy it.

    Second argument:

    Kerckoffs's principle: A cryptosystem should be secure even if everything about the system is known.

    Agreed. This is basically the motivation for not storing your passwords as plaintext in the first place. But if my response to the first criticism stands then these wacky hashes still function as secure hashes, and our system doesn't break Kerckoffs's principle anymore than it would with a standard hash.

    Here are two possible (and worthwhile, as far as I can see) advantages to using a "wacky" hash over a normal hash:

    1. Sure, your system should be secure if the attacker has the source code, but it's a very likely possibility that your attacker wont have access to your source code and probably won't be able to guess your wacky hash, making any attempt at a brute force impossible.
    2. (This one is the real motivation behind me asking this question) BCrypt is thought to be secure, hard for the CPU and GPU (great) but can be very fast with specialized hardware. SCrypt is said to be hard to bruteforce on CPUs, GPUs and currently available specialized hardward but is more recent and not trusted by the cryptographic community as much as BCrypt due to the lack of exposure it's had. But doesn't the hash BCrypt(SCrypt(password + salt)) get the best of both worlds?

    I appreciate that the passion/anger behind most rants against these home-brewed hashes comes from the average programmer's lack of knowledge of what makes a good hash, and a worry that encouraging this sort of wacky-hashing will inevitably end up with weak and useless hashes getting into production code. But If the wacky hash is carefully constructed out of solid and trusted hashes, are the gains in security not very valuable and real?


    I got a bunch of good answers on this, thanks. What I seemed to be overlooking in my assumptions was that, although combining hashes can't make it easier to crack the original password and therefore crack the constituent hashes, the combination of two or more secure hashes can - at least in principle - be weaker than any one of its inner hashes due to the unstudied and complex interactions between them. Meaning it could be possible to find some string that got past the wacky hash without necessarily breaking the hashes that made it up.

Related questions and answers
  • trust one's VPN provider to be an exit point for all of one's Internet activity, because not all websites support HTTPS, and a VPN provider can observe any of your HTTP transactions. For example, I'm posting this question over HTTP now. To solve this problem, I purchased my own VPS to run my own VPN. A good start, but there's still a problem. In China, most of the VPN protocols are blocked. L2TP..., because it's very easy to set up, and the Obfsproxy project promises protection against DPI -- so it can't be blocked by Chinese ISPs. My questions are, Does Tor really provide VPN security features

  • technical flaws that can be exploited. I want to create some real life but not hard to crack scenario so that attackers can experience something new rather than just downloading the VM from internet... on that would be appreciated. I request you to advice on what more could be there to make this exercise suit an intermediate level of pentesting and putting a challenge up, even better if it can...I request you to read the problem before suggesting any duplicate or down-voting, I am well aware of hundreds of questions about somewhat similar problem but this one is just to attract some good

  • security measures exist(e.g. protection against online brute force attacks, requiring strong passwords when registering/updating the password, warning the user for possible failed login attempts... when trying to login. E.g. the user can choose the current (day + 7). So, if my password is myPassword, and today's date is 11, then I have to type myPassword18. Which means that if I have to login on another day I will have to insert another "total" password - based on that day. Of course the date is an example, it can be different variable type, e.g. the first 3 letters of my current ip address

  • The question below goes from a wrong assumption that attacker is able to spoof IP when making HTTP connection. But attacker isn't able to spoof IP if he doesn't have direct access to connection... are the main activities that are made possible after setting up attack detection using logging, IDS and SIEM. My comments why they seem not efficient are also below. Block attacker We may block requests... if spoofed, is a needed action. However, attacker is able to flood server with various malicious-like requests. I can't block all of them as they are too different and any IDS will have false negatives. I

  • (PBKDF2_ALGORITHM); return skf.generateSecret(spec).getEncoded(); } Now my question is : How should the Keyed hashing for the password be implemented ? Based on my reading, this is my...As mentioned in this wonderful link, the way to get a PBKDF2 Hash of a user given password given a password (of course), a salt (generated Cryptographically Secure Random Number Generator. iteration count (chosen high enough to be secure while balancing your application's usability tolerance) Hash size (length of the hash to be computed) /** * Computes the PBKDF2 hash of a password

  • ) the time to 'crack' it is orders of magnitude greater than the required time for the other, hence, it is more secure. Is this concept sound? In lay terms... Shall I change all my passwords... this question should be asked on StackOverflow since concerns more with practical use of low-entropy passwords in computer systems authorization mechanisms woth regards to password cracking. Don't... of data. If so, you'll have noticed that the first, stronger password has much less entropy than the second (weaker) password. Virtually everyone has always believed or been told that passwords

  • the backup and was wondering why it takes so long. I was puzzled to see that the changes have increased from the normal 5% to 50% ! Alarmed, I mounted both volumes (old one and the current one) and made a file compare and could not see any reason for the increase. I have no knowledge how exactly TrueCrypt lays out the data internally, but as a file system the simple explanation could be that some... times. No bigger changes occur. The number of segments is 320, by the way. The next step for me will be to find long byte chains and see if I can locate them on another place (so that my suspicion

  • of prepending the constant PBKDF2_ITERATIONS to createHash(char[] password) method? Is my understanding of the whole process correct? Here is the link to my source code - which value should I save as hash...Context: I am using this tutorial and trying to understand and implement salted password hashing using Java. After spending some time on this topic, I figured out that the basic idea is to: Convert the password string to a character array. Generate a random salt using SecureRandom(or similar). Hash the password character array with a standard cryptographic hash function. Convert the salt

  • , with the smartcard unavailable, I have to make sure I have a private key available on server B. Therefore, I created a password-protected RSA ssh key pair with on server B using ssh-keygen -t rsa The password... to server A works now. Vice-versa also works now. Problem On Windows at site 1 I have a PuTTY connection set-up to server B using agent-forwarding for my smartcard in order to be able to use git... here. OpenSSH to GnuPG S/MIME First we need to create a certificate (self-signed) for our ssh key: openssl req -new -x509 -key ~/.ssh/id_rsa -out ssh-cert.pem We can now import

Data information