Can I ask a broad question of what the “correct” cypher is for hashing these days?

bcrypt for stuff like that imo

@Patrick thanks - is that because the work factor is easier on the host architecture for bcrypt than pbkdft2?

yea its much easier work factor for sure. Are there gov specific requirements or what is your issue on the pbkdft2 approach- just that its a lower SHA?

No - there’s no hard requirements on what I use beyond some of the clients that need upgraded being on some hardware that may not cope as well with the increased resource requirements of one over the other

Yea I would put bcrypt at easier and maybe same level field around memory as pbkdft2, Bcrypt for avg projects has always worked solid, Gov stuff goes way diff path.

great, all I need to know really

haha oh yea those days of fun

It makes me feel old when I think of it but also nostalgic since it basically led to here and it’s turned into a better resource for all cf devs!

honestly I had totally forgot about that until you mentioned it there lol

It’s a niche language so unexpected benefits when you’re not expecting it! I’ve just joined a company whos senior staff I met years ago at CFCamp so

Previously used bcrypt, but switched a while ago to Argon2id as it's well regarded and Lucee has built-in support. https://docs.lucee.org/reference/functions/generateargon2hash.html

yea that is another good one, wasnt sure on usage/weight

Thanks @cfsimplicity, I did look at that but wasn’t sure where to look for details on the impact of its memcost argument and parallelism

Just a quick search and it appears that Argon2 is memory intensive to prevent gpu attacks

thus far I’ve never had to pay any attention to how long it might add to a users log in time or how complex it might make that process

yea its a give/take thing to analyze, and something on an average playing field should be decent enough with the assumption that you have other methods in tact to prevent brute; aka 5 login attempts block, other various WAF stuff

Yeah was just about to say I’ve utilised login attempts and other things to mitigate risk

Cloudflare is a great starting point if public facing

Of the clients that are public facing cf has not been a viable option due to cost, being behind a nat gateway or needing a static ip, and/or lack of knowledge on my part of whether implementing it would be the solution

yea if internal your risk is substantially lower but still should not be discounted, so hardening even with bcrypt is a good step forward.

the hardest part is figuring out how to convert the existing to the new process. Before what I’ve done is just double hashed

Typically I would implement a user must change password approach within their next 5 login attempts or something

We've transitioned a few times without requiring users to reset. It's always been possible to detect what algo was used for the hash stored for a user, so when they next log in, if it's a legacy hash then authenticate using that algo. If successful, hash and store the presented credentials using the new algo. To avoid a prolonged transition, you can require a reset after a certain period of not logging in, which people expect anyway.

@cfsimplicity that’s kind of what I did before, hence the double hashing

You mean hash it w old algo to validate the login, then w the new one and store it, so there's nothing the user has to do. Right? Just to say it, the whole point of bcrypt is that the work factor can or does expand over time, so tomorrow's faster computers can be made to be slow enough trying a bunch of possibles that trying a ton of them is prohibitive. Faster and less memory intensive is the opposite of better, unless you don't care how easy it is, in which case maybe don't worry about this much.

java added the some post quantum level crypto recently

@zackster is that over engineering though 👀

my dearly beloved password1 needs a lot of protection!

well if we’re being honest/realistic it doesn’t matter what it is as long as it’s hashed properly!

In cryptography REALLY gives you a buzz - the NIST website is an absolute goldmine of information / presentation notes/slides and articles on advice (like Password for parents with young children) In a cryptography presentation (by this I mean attended by mathematicians who create and attack algorithms) in January this year, it was stated that BCrypt it not suitable for password hashing after the Aug 2022 breach of LastPass. The hacker(s) are still unknown and the LastPass hack has been named as the source for hundreds of millions of dollars(USD) of stolen cryptocurrency from wallets. It went on to say that the current implementation of Argon2i is susceptible to an attack vector known as "Pebbling". (there are 3 variants of Argon2. 2i, 2d and 2id. 2i is specifically used for password hashing - 2d is used for hashing data (files) and 2id is a combination of both.) Despite Argon2 winning the hashing competition and despite the lobbying to NIST for its inclusion in the "Approved" list, it is not likely to be approved until the Pebbling vulnerability is addressed and a substantial amount of time (time to be tested / hacked / etc) has passed to prove its robustness. None of this is to say that BCrypt as an algorithm is a poor choice - or that you should avoid Argon2, either. Despite the current state of things I have applications where Argon2 was specifically requested - even with the knowledge of the Pebbling attack vector. I personally flip-flop between BCrypt/Argon2 when choosing an algorithm. They are both spectacularly better than MD5/SHA-1. The very best advice at the present time is: Use a password generator for passwords. Use a Memory intensive algorithm Despite the constant attacks, use a password safe. Use a "local" one as opposed to online - if you're concerned about the online presence. (Backup your password database regularly) Or use a hardware password safe - instead of a software safe. (I use a yubikey - there is an NFC version and you can get them with fingerprint scanner too. There is also a FIPS certified version if you're paranoid / need a govt approved device. (Just because I am paranoid - doesn't mean THEY aren't out to get me! 🙂 ) AND use MFA. It is a real pain BUT is the current strongest protection we have. (As long as you ignore the fact that it is entirely possible to receive another person's phone calls and SMS messages - without THEIR phone ever ringing / getting the SMS) Of course - YOU would have to be targeted for exploitation for this level of scrutiny...

@gavinbaumanis Do you have a link to the NIST discussion about BCrypt and the LastPass breakin? I don't understand how that (terrible) event relates to the security of BCrypt in other contexts.

Here is some good insight to bcrypt: https://specopssoft.com/blog/hashing-algorithm-cracking-bcrypt-passwords/ @Dave Merrill

Good article, but unless I'm thick, it doesn't link any vulnerability in BCrypt to the LastPass incident. Yes any credentials contained in that breach are at risk, but that has nothing to do w BCrypt, and doesn't make BCrypt any less secure. Yes short, common, reused, and known-compromised passwords are a huge risk, but again that has nothing to do w BCrypt. What am I missing?

If I remember the details of the same incident it was encrypted data taken not hashed

FYI, I think the max length string that BCrypt can hash effectively is 72 characters, it truncates the input beyond that. This SO page talks about it. I'm not 1 million percent certain that old info still applies, but I haven't found anything saying otherwise.

That's interesting I wouldn't think there was a maximum

Depends on how you have your password app configured to generate them 🙂

I think part of the point regarding bcrypt is related to the lead into quantum computing being able to crack stuff faster etc but in a normal realm app environment it is perfectly fine at the moment. @Dave Merrill