For security, in the past, I've used

hash()

with an application and a per-user salt to generate passwords. With a new app I'm working on, I'm looking at bcrypt but from what I've read it doesn't have the concept of an application and per-user salt. Is adding an application-wide workfactor enough? Should I also top-and-tail the password with the two salts as I've done in the past?

Bcrypt is quite safe. There is a lot of info on bcrypt here https://auth0.com/blog/hashing-in-action-understanding-bcrypt/ Bcrypt has some standard output with algorithm, workfactor and hash already included

So the old approach of adding a salt to your password is not relevant if you're using bcrypt?

To which bcrypt library are you referring?

Sorry, I'm looking at this on Forgebox - https://forgebox.io/view/BCrypt

Yes, I am using that one most of the time. But I also used the plain java version some times. The forgebox version is easy because it is hiding some details, but that also makes it harder to understand.

Yes, I am using ColdBox. I did look at the guts of

hashPassword()

and saw that

salt

has to be an

int

like

workFactor

so it couldn't take my user salt.

string function generateSalt( workFactor=variables.settings.workFactor ){
	return variables.bcrypt.genSalt( javaCast( "int", arguments.workFactor ) );
}

no, I think that’s not true

Yes,

generateSalt()

does return a string but I can't

hashPassword( password='myUserPassword', salt='myUserSalt' )

because I get back _"Invalid salt version_"

Indeed. I thing that’s specific to this bcrypt java library. For some stupid reason it detects the workfactor from the salt. Just see what’s going on here. If you do a hasspassword with a workfactor 12 but supply a genSalt(8), it ignores the workfactor 12. So in this case the bcrypt forgebox is slightly wrong, it tells you you can use a custom salt. But the only ‘custom’ salt is one which is generated by bcrypt. Not so custom at all, because it does so by default

I guess I'm so fixated on the "old" way of hashing passwords with an application salt, a user salt and

hash()

that I'm trying to apply this to bcrypt. Maybe I should relax and drop the application and user salt from my app. Thanks for your insight.

@dick The short answer is you don't need to worry about salt at all yourself. bcrypt takes care of all of that for you and it creates a per-user salt automatically. All you need to do is give it the password

Thanks for the confirmation @bdw429s

What you call an "application salt" is typically called a "pepper". The important difference from a salt is that is must not be stored in the same place as the output of the hash so that if all output hashes leak (i.e. your database is breached), the attacker still misses a piece of the puzzle.That could be important to protect really weak password (like "987654321" or others from the top most occurring passwords), even if your workfactor causes a single hash to take half a second or so. For that it must have sufficient entropy (current NIST recommendation is 122 bit, so a random UUID would be good) .

Ah, thanks @Jochem, I never knew that concept was called "pepper" but it makes sense! I've been using that technique for many years but with this new project coming along I thought I'd look at bcrypt which now seems to be the advised way to go.