Password hash salt


#1

Is there a built-in Lucee function for creating passwords with hash salt, etc? I’ve found a few examples that are a few years old.

I don’t want to reinvent the wheel. What would you recommend for best practice password security? Thanks again.


#2

Hashing a password with a salt can be as simple as:

hash( input=password & userID, algorithm='SHA-512', numIterations=1000 )

In that case, the userID is used as a salt for the password so a single lookup table couldn’t be created for your entire database. I’d recommend using a library like bcrypt. If you’re using the ColdBox framework, all you need is:

install bcrypt

And then

var hashedPassword = getInstance( "BCrypt@BCrypt" ).hashPassword( plaintextPassword );

You can still use same library outside a framework, it’s just more trouble.


#3

Bcrypt also has salting built-in so you don’t need to add your own.

If you’re not using ColdBox then the cfpassphrase library provides a nice wrapper for bcrypt, along with a couple of other algorithms.


#4

Bcrypt also has salting built-in so you don’t need to add your own.

Small caveat for salting with bCrypt, if you do end up using a salt anyway, you need to add it AFTER the user provided string.

The way bCrypt does encryption only the first 72 characters are relevant. If your salt is 72 characters long all users will end up with the same encrypted value.

Ref: https://stackoverflow.com/a/6180209/70424


#5

Time for hash to support bcrypt?


#6

I’ll add that for storing passwords in a database, I’d also encrypt() the hashed/bCrypt result with a strong cipher block mode, like AES/CBC/PKCS5Padding. I store mine triple encrypted using three different keys and algorithms.

See https://github.com/ddspringle/framework-one-secure-auth for this and additional security considerations and examples (code and concepts can be applied to any application or framework - this just happens to use fw/1).

More details on the how and why the techniques demonstrated in that code are used can be gleaned from the cfdocs security guide at https://cfdocs.org/security - specifically the ‘code security’ sections (scroll down to the bottom of that doc for links to obfuscation, encryption, authentication and session management).

As a side note, good to see CFML devs thinking about security!

HTH

– Denny


#7

Thank everyone for this very helpful information. I do have a question that I have been thinking about.

The passwords would be stored in a database. They would be created and retrieved with lucee. But they may also be retrieved and created through other api or micro services that would be written in node or python.

What would be the best approach for password security considering that the passwords are stored in a database . most likley postgres and need to be usable by python and nodejs authenticating then as well ? Would using the strategies above be comparable with other languages?


#8

Most hashing algorithms are standard across platforms. i.e. the MD5 hash of a given string is identical regardless of where or how you hashed it. That said, I’m not positive about Bcrypt (which is really the Java library JCrypt, I think). I’m pretty sure it uses a high number of iterations of blowfish encryption (it’s not technically a hash, per se) with an auto-generated salt. I’m not sure if other implementations of BCrypt follow the exact same recipe. You can always roll your own process with a common hashing algorithm, like 10,000 hashes with SHA-512 or something, but keep in mind the idea is that the “work factor” is slow enough to help prevent the feasibility of brute force attacks, but not too slow that it makes your website logins unbearable.

Another suggestion is that you funnel all your authentication logic through a web server you expose, written in CFML, and all your Python or Node.js uses your API to authenticate users. That will allow you to massage the actual storage in the future and keep you from having to write the same routines over and over in each language.


#9

The same can be said for encryption algorithms in that they are pretty standardized across platforms - so as long as you are using encryption that Node and Python have support for, say AES/CBC/PKCS5Padding, then it shouldn’t cause any issues for you.