Best / Strongest Password Hashing Method for ColdFusion

Hello, everyone,

What is the best / strongest password hashing method for storing things like passwords in a database? Something that can be done in ColdFusion (even if Java, but I’d need LOTS of help, since I know nothing of Java).



The best way to store passwords is BCrypt with at least a 10+ factor.


Thanks, @mawburn. I was hoping that the site wouldn’t be blocked and that I’d be able to download the files… for once, no issues, there. :smile:

I’ll give that a shot and report back how well it did or didn’t work.



How can I set this so that it doesn’t use javaloader? I’m not seeing instructions that don’t use javaloader.

I’ve extracted the files to the root of my project folder;
downloaded the .class file and put it in %system%/Java/JDK;
added a path to %system%/Java/JDK in Java/JVM > Class Path;

… now I just need to define the variable “BCrypt”, and I should be good to go.

UPDATE: Nevermind… :slight_smile: I did manage to find the answer on AliasPoorYorik (BCrypt = CreateObject("java","BCrypt"))



1 Like

Wow. The difference in the amount of time between factor 10 and factor 15 is pretty amazing when you consider that you can go as high as 31!! (Apparently, each step up in the factor doubles the time it takes to hash the value.)

This is working GREAT! Thanks, again, @mawburn for suggesting BCrypt. Quite nice!

Have a great weekend… I’m heading home, early, today.



The difference in the amount of time between factor 10 and factor 15 is pretty amazing when you consider that you can go as high as 31!!

Yeah, it’s great. Most people use 12 like the blog post I sent. But by doing it this way, you can scale your passwords with any breakthroughs in technology since it stores the work factor with the password itself.

BCrypt is the algorithm used in default PHP password_hash function and has an implementation in most other languages.

Browser Stack recently claimed that their passwords were unbreakable because of BCrypt during that hacked email thing a couple weeks ago, but that’s false. It’s just a strong hash. Which means that all you have to do is generate every possible combination to break a password. But, as you saw this can take a very long time to break even a single password… but it’s not unbreakable.

I’m heading home, early, today

Yuck. They gave us off. :smiley:

I could have taken the day off, but it would have used “floating holiday” hours that I would rather keep for a later date. :smile: Today, however, I wish I had taken off work… icy, slick roads and parking lots. Almost killed myself just getting out of my car (after having spent 15 minutes scraping ice off my windshield, I’d have been pissed to die so casually.)

Thanks for the suggestion… BCrypt is killer and was easily integrated into my CF server. :smile:


1 Like

I am experiencing a weird issue with BCrypt.

Just for fun, I decided to pump it up to 31 and it instantly generated the hash.

I set it to 29 and did a submit, and it just sits there. It’s been processing for at least ten minutes, no error messages, no hash. Just going and going.


I’m going to wager a slightly speculative, slightly educated guess that it’s silently reducing the cost parameter.

The “educated” part of this guess comes from the fact that libraries in the PHP world did the same thing. The phpass library, for example, would silently reduce the cost to 8 if you passed a value greater than 31. (Not very smart of phpass.)

But this is also very speculative, because you’re not using that library. You’re not even using the same language. And the effect should only happen if you exceed 31, not 30.

1 Like

As I understand it, BCrypt essentially IS the encryption that is in PHP. It’s a Java class, so I don’t think it would be language specific. All I had to do was put the folder in the root of my project, put the .class file in with my other classes, and restart the CF service.

I did contact the author, explained what I am experiencing, and am awaiting a reply. (At least, I hope the author is still monitoring that email address. :slight_smile: )


Sounds about right. It’s an exponential increase and 29 is probably going to take at minimum a few hours. Maybe a few days or possibly even a week or more.

It’s 2^workfactor so it’s processed that many times. So that means 12 is processed 4096 times, 13 is processed 8192 times, and 29 is processed 536,870,912 times.

So going by his benchmarks, that’s 0.11173756 ms to about 0.3ms per process, so say .2ms per process on average. That would mean a 29 work factor would be 107374182.4ms or 1.24275 days.

I suppose that could explain the factors like 29, but what do you think about the 31 factor instantly generating the hash with absolutely no time delay?

No clue. @Jeff_Mott is probably right on that one.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.