Docs
cfPassphraseOverview
• Code
This FAQ attempts to cover any questions that you might have about cfPassphrase.
If you have a question not covered in this FAQ or elsewhere in the documentation, please use the issue tracker.
The aim of this project is to make passphrase hashing as easy as possible for CFML developers to implement.
This project doesn't do much which can't already be done with createObject Java calls and appropriate CFML code, however it collects everything into a single package which aims to work consistently for every CFML engine.
It is not required to know anything about the algorithms involved, however it is recommend to read at least the Tuning Algorithm Params page.
If you already have a working implementation of an industry best practise key derivation function (i.e. BCrypt/PBKDF2/SCrypt), there is no direct additional benefit. However, the cfPassphrase project aims to provide a standardised implementation across all CFML engines and thus will hopefully become something developers are familiar with.
If you simply use the Hash or Encrypt functions it is possible you are storing hashes which are vulnerable to brute force attacks - even though you might be salting them - and it is recommended you use cfPassphrase instead.
A password is a passphrase. As their names suggest, a password is generally a single word (or jumble of symbols), whilst a passphrase is multiple words, making up a secret phrase.
Using passphrases is recommended for two reasons:
A passphrase is longer and usually contains higher entropy, making them harder to guess (and thus more resistant to brute-force attack).
A passphrase can be easier to remember, and it is also possible to write down a single word from a passphrase as a reminder, without compromising the whole phrase.
As with regular passwords, do not use common or predictable phrases. The use of at least one non-dictionary word is recommended; mixing up punctuation and substituting letters can also help.
The default algorithm used is BCrypt. PBKDF2 and SCrypt are also available.
The Algorithms page goes into more detail.
Ask three different people and you will get four different answers.
If in doubt, stick to the default algorithm (currently BCrypt) - it may or not be the "best" choice, but in almost all cases it will be good enough.
There are some people that claim you should not use BCrypt, and will recommend either PBKDF2 or SCrypt instead, but equally there are those that point out why BCrypt is better than PBKDF2, and that SCrypt is currently too new.
Check the Further Reading section on the Algorithms page for assorted views.
Remember: Whilst a strong algorithm is important, it will not protect against badly chosen passwords - educating people to use at least eight characters and not to use common words is more important than deciding between these three algorithms.
At the time of writing, I am not aware of any key derivation functions which implement these new hash functions. As and when that occurs they will be likely be added.
However, given that they are new it may be some time before they are recommended for use - a general rule of thumb is to wait at least five years before using a cryptographic algorithm, to see if any weaknesses in it are discovered.
It is designed to be slow! The purpose of all the algorithms used is to combat brute force attacks, by using operations that are slow and cannot be bypassed.
The default parameters used by cfPassphrase are intended to make it too costly (in terms of time and equipment) for an attacker.
As always, there is a balance between security and usability. If you find cfPassphrase is running too slowly, you can adjust the parameters used to speed it up - but should take care to ensure you don't reduce them too far.
See Tuning Algorithm Params for further information about this.