In the past I’ve been using cborm a lot, since it makes handling coldfusion (hibernate) ORM so much easier. But lucee support for ORM was less than optimal in a multi-datasource environment, so I decided to rewrite this application more or less according to the fluent API approach as demonstrated by Gavin Pickin at ITB 2020. In this coding style I have two quite efficient ways of populating a new object:
property name="UserService" inject;
var user = populateModel(
//vs a shorter method
var user = UserService.new( myUserData );
Both should return the same populated user object, but the second one does the population within the new() method, so I got used to using this handy method.
I have to admit. This is not the most useful post I ever wrote, but today I discovered something funny but interesting when I tried to fix some small bug. I was working with the bcrypt module. If you don’t know what this module is doing: it is a very secure way for hashing passwords, and since checking the validity of your password is relatively slow it is quite useful to prevent password cracking. Before diving into bugfixing let’s see what bcrypt is doing. It is a coldbox module and only has a few relevant functions:
hashPassword(password, [ workfactor], [salt]) which generates a password hash based on a salt and a workfactor. If you don’t supply a workFactor or salt, the coldbox module will generate a salt with a default workfactor of 12. The higher the workfactor, the longer it takes to check for a valid password. (on my system a workfactor means it takes 200 milliseconds to check for a valid password.
checkPassword( candidate, bCryptHash) will check a password candidate agains a (stored) bcryptHash.
generateSalt( workFactor ) will generate a salt, based on a workFactor. Increasing a workfactor by 1 will mean it takes double the time to check your bCryptHash. This way you can prevent password attacks, because generating and checking is relatively slow.
We all know. We should never ever store a plaintext password in a database. If a hacker gains access to your data you will be in serious trouble. There are many ways to protect your data, but at least you should make sure your passwords are not readable. In the past we did this by some simple hashing, but modern computers are so fast it is easy to do some password cracking. In time it even gets easier because processors are becoming faster and faster. Another disadvantage: simple hashing will reveal some records with the same passwords. These are often the easiest to guess or crack by brute force. So we need something better.
Coldbox has a nice little module called bcrypt, which is just a wrapper to the jBcrypt java library which is a Java™ implementation of OpenBSD’s Blowfish password hashing code. Wikipedia has a nice description of the bcrypt password hashing algoritme. Bcrypt hash some strong points:
- generating a hash for the same string will always return different results
- comparing a password candidate with the stored hash is relatively slow, which makes brute force attacks harder.
- the hash can be generated with different workfactors. The higher the workfactor, the more time it takes to compare your hash with a password candidate. By increasing the workfactor in time you can account for faster processors, so brute-force attacks remain unattractive.