Is there an overall advantage to using a global secret key in addition to random item-level salts with bcrypt password hashing?

Question

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?

Looks like a question here: http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough answers the very question I'm looking to find the info for, which is great. — Kzqai, Apr 27 '12 at 18:34

score 3 · Accepted Answer · answered Apr 26 '12 at 06:29

3

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.

answered Apr 26 '12 at 06:29

Nick Johnson

100,655
16
128
198

Fair enough, I like the clearer terminology of global secret key vs. global salt. I agree that this scenario is only applicable to an attack surface where the server itself has not been compromised (or at least the application source code and the application config files). However, I do find that to be a pretty compellingly large possibility. First of all, with sql-injection tools, it's potentially possible to map out all the data in a database and the structure using a single unclosed hole. Same with database backups. Whereas if the server is compromised, all is lost anyway. – Kzqai Apr 26 '12 at 15:11
@Tchalvak Like I said, opinions differ. If your site has an SQL injection vulnerability, though, the attacker can do other things, like promote themselves to administrator, at a minimum (which will provide them with other avenues to exploit). And if your input sanitization is that lacking, there are probably other ways to persuade your server to give up the information they want. – Nick Johnson Apr 27 '12 at 01:25
If applied properly salted hashes don't allow you to construct the unsalted hashes, and thus, an added benefit of using salt is that it prevents attacks using rainbow tables even if the salt is compromised. – Paul Aug 06 '12 at 10:43
@Paul A 'global salt' as the OP describes would only prevent the use of a generic rainbow table; the attacker could still construct a site-specific one. – Nick Johnson Aug 22 '12 at 10:04

score 0 · Answer 2 · answered Apr 24 '12 at 21:50

The purpose of salt and stretching is to make things hard for hackers to crack pwds if they access the database.

If you add an additional global salt in the app, then you are basically distributing your login process between app and db, which makes things more complicated than necessary and opens more venues to attacks.

What are you going to store in the db, the hash including the global salt or not? And then, what are you going to have to transfer between db and app during the login process? The communication should be secured between your app and the db anyway (otherwise your salting system can easily be broken with man in the middle).

There might be a tiny benefit if hackers only have access to db and never to app, but honestly, this is a very tiny non-realistic case today. Hacker will get access to your app before your DB. It is not worth the effort. Moreover, I may even be wrong.

Very often, people think of 'new' ideas when it comes to security, only to be smashed by hackers, because corner cases have not been identified and studied properly. It is a classic in cryptography. Thousands of those ideas have failed dramatically and cost those who used them a lot of pain. Creativity is a liability in cryptography.

Stick to the classic secured communications + random item-level salt scheme.

Certainly it does make things more complicated, not sure about the "than necessary" part. In the database the hash would be stored. In the application config files the global salt/(Nick Johnson calls it a secret key) would be stored. The "your implementation may introduce insecurities" argument is a little compelling, though. I don't really trust myself to do the implementation, but I think that I'll look further into more mainstream implementations that use global secret keys, if any. — Kzqai, Apr 26 '12 at 15:15

Is there an overall advantage to using a global secret key in addition to random item-level salts with bcrypt password hashing?

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

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?

2 Answers2