Home/ Questions/Q 7847805
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T18:00:27+00:00

I use bcrypt for password hashing in php 5.3+ I understand that bcrypt uses

  • 0

I use bcrypt for password hashing in php 5.3+

I understand that bcrypt uses a random salt that gets built into the resulting hash per item. This makes cracking each hash difficult, and prevents cracking

What I don’t know is whether there still exists good reason to use an additional, application-level global secret key.

E.g. instead of just hashing a password string, e.g. “password1” into a bcrypt hash with the random salt that is built into the bcrypt generation system ( as per here: https://gist.github.com/1053158 ):
$2a$08$mjQAZ5cZi5B9u6zpUU4mGuRcvtxr1K.9ncYpxCdG.YhlD8yFG2mXK

I could also create a constant, e.g.: “@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%” , put that constant into the application (either into the application source code or the application’s configuration files), and append that to any string to be hashed.
So “password1″+”@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%” -> would get hashed into a different hash from just “password1” alone.
$2a$08$xFgULsrpoIYlbxp1IG3H8.kdVggyhm4aTQXrP2Ptu25nMBUjBdrrK

Obviously in the context of the application itself, this doesn’t help much. If someone tries the password “password1” on the running system, they’ll succeed, because they’ll automatically get the global secret key along for the ride. But if they have the database or access to the database only, it seems like the global secret key may be an additional obstacle? Because, not knowing the global secret key, they would have to crack “”password1@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%” instead of just cracking “password1”.

There are some potential benefits that may exist that I can imagine:

  • This might really hinder cracking the hashes using a compromised database alone?

And some vague disadvantages that may exist:

  • This introduces a common thread to all strings that get hashed, which may make it easier to crack hashes if it’s known.
  • It increases the fragility of the data. If the global secret key is lost, e.g. during a server migration, or whatever, the data is now trash.

So I’m trying to figure out whether it’s a good idea to also have a global secret key, or whether the random salt per item is both enough, and all you want. Does anyone know of any implementations that use a global secret key, or research that suggests using it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The sole purpose of a salt is to defeat precomputation attacks (eg, rainbow tables). What you describe as a ‘global salt’ is, in fact, a secret key.

    Opinions differ on whether this is useful. The only threat model it helps defend against is one where the attacker can get the contents of the database, but cannot access your source code. Personally, I’m of the opinion that this is a sufficiently narrow possibility that defending against it is unnecessary, and the amount of effort required to do it properly is unwarranted.

    • 0