-1
$\begingroup$

I am thinking to create own hashing Instead of creating encryption(weak). That hash function has some number of cryptic parameters to go before it stores in db? Does it become unhackable if I do so?

$\endgroup$
3
$\begingroup$

You can "create your own hash" e.g. by using HMAC with a well-studied standard cryptographic hash function (e.g. SHA-512) and a hardcoded secret key (e.g. a randomly chosen 64-byte string). This gives you the best of both worlds:

  • As long as your code (containing the key) is not leaked, the keyed hash is provably secure (i.e. computationally indistinguishable from a random function, subject to some relatively mild assumptions on the underlying hash function).

  • The security of your hash is not based on your own cleverness, but on a well tested (and mathematically analyzed) standard construction, plus the secrecy of the key. In particular, you can safely submit all your code except for the secret key to third-party security analysis without compromising its security (and, since it's based on standard components plus an interchangeable key, it is in fact possible for someone else to effectively analyze its security).

  • Even if your secret HMAC key is leaked to an attacker, the system still retains the same security properties as the underlying hash (i.e. collision and preimage resistance). For many purposes, these are sufficient.

  • In the event that your code and key are leaked (or you suspect that they may have been), the only thing you need to do to make the system fully secure again (besides plugging the original leak, obviously) is to change the key — you don't have to redesign your entire hashing algorithm. Since the key can be any random string with sufficient entropy, changing it is very easy.

  • You can easily create multiple independent versions of the hashing algorithm just by changing the key. Each of them will be equally secure (assuming that the keys are all randomly chosen with the same amount of entropy), but none of them can be used to break another one.

Of course, instead of hardcoding the key directly into your hashing code, it's generally even better to store it e.g. in a config file. That way, you're free to share your code safely with other developers, without having to trust them with the key (or having to always edit it out before sharing the code).

$\endgroup$
1
  • $\begingroup$ Alternative (similar) idea: Instead of HMAC use one of the new PHC winner schemes which support pepper (secret input). $\endgroup$
    – SEJPM
    Aug 17 '16 at 11:59
3
$\begingroup$

One key point in cryptography is to never base your security on the algorithm being private. That's a practice a lot of companies have made and failed miserably.

Current takes on new cryptography algorithms is to make them public and challenge other people to break them.

$\endgroup$
1
  • 1
    $\begingroup$ Please define securing website. What do you want to secure on that website? $\endgroup$ Aug 17 '16 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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