bscrypt is a modern alternative to bcrypt; also cache-hard and more suitable than Argon2 and Scrypt: cache-hard, easier to deploy on multi-user environments, as well as web browsers/mobile devices. https://github.com/Sc00bz/bscrypt
[deleted]
Bcrypt at 25
41–50 of 78 posts
Re: Bcrypt at 25
#42See also "A Popular Password Hashing Algorithm Starts Its Long Goodbye": * https://www.wired.com/story/bcrypt-password-hashing-25-years...
It's weird to see people saying that Bcrypt's "moment is passing", because it isn't. The whole concept of adaptive hashing is that they're future-proofed: they're parameterized by the degree of pain they inflict on brute force guessers, and they take advantage of the imbalance between guessers and validators.
Argon2 and scrypt do this more efficiently than Bcrypt (which in turn does this substantially more efficiently than PBKDF2, which is still widely used, in part because there are regs that lock it into place), but you can more or less throw a dart at any of these algorithms to competently choose a password hash.
What I understand Niels to be saying here is that passwords are nearing the end of the road. I see why people think that! But it's also been an annual prediction since the 1990s, so I'm a bit skeptical.
Re: Bcrypt at 25
#43bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.)
mac(bcrypt(mac(password, secret_key)), secret_key)
1) The output of `mac` might need to be encoded in an ASCII-clean way, e.g. using base64, as some implementations don't do well with embedded nulls or 8-bit data.
2) `mac` should produce 72 bytes of data or more. Truncating is better than padding.
3) An appropriate cost should be chosen, 12 or 13 seem to be common choices and should provide a large enough security margin.
Re: Bcrypt at 25
#44bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.) mac(bcrypt(mac(password, secret_key)), secret_key) Thi…
The reason people suggest HMAC or keyed hashes with password hashes is that they believe this foils attackers who steal password databases but not the HMAC key. Of course, that begs a question: if you have a place to store an HMAC key where attackers can't get it, why not just store the password hashes there? In reality: if you've lost your password hash database, your application has been game-overed. You don't hash passwords to further protect your own app; you do it to protect everybody else who is exposed to the inevitably shared passwords that users use.
Don't do stuff like this.
Re: Bcrypt at 25
#45bscrypt is a modern alternative to bcrypt; also cache-hard and more suitable than Argon2 and Scrypt: cache-hard, easier to deploy on multi-user environments, as well as web browsers/mobile devices. https://github.com/Sc00bz/bscrypt
Is it verified, peer-reviewed? I can't find much about it
I don't have anything super productive to say here and this comment is more emotive than substantive but I'm going to say it anyways: it is remarkable to me how much peer review people demand from password hash constructions (which are quite unlikely to fail dramatically) than from every other cryptographic primitive they use.
Re: Bcrypt at 25
#46bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.) mac(bcrypt(mac(password, secret_key)), secret_key) Thi…
> optimized for the wrong kind of "computational hardness", i.e. cache/memory hard
You got that backwards. Alternatives like Argon2 are way more expensive for attackers because they can be configured to be memory hard
Re: Bcrypt at 25
#47See also "A Popular Password Hashing Algorithm Starts Its Long Goodbye": * https://www.wired.com/story/bcrypt-password-hashing-25-years...
It's weird to see people saying that Bcrypt's "moment is passing", because it isn't. The whole concept of adaptive hashing is that they're future-proofed: they're parameterized by the degree of pain they inflict on brute force guessers, and they take advantage of the imbalance between guessers and validators. Argon2 and scrypt do this more efficiently than Bcrypt (which in turn does this substantially more efficientl…
2023 will be the year of the password-less Linux desktop
Re: Bcrypt at 25
#48Earlier quoted context omitted.
Is it verified, peer-reviewed? I can't find much about it
I don't have anything super productive to say here and this comment is more emotive than substantive but I'm going to say it anyways: it is remarkable to me how much peer review people demand from password hash constructions (which are quite unlikely to fail dramatically) than from every other cryptographic primitive they use.
Well, I don't know about that. I really want all algorithms and implementations checked out by at least a few people that write up a report. Even something like Blake3 could be a bit iffy under that criteria.
Re: Bcrypt at 25
#49Earlier quoted context omitted.
Equal rights for everyone, anyone can use any account. Later on, and still today as default in GNU software, he also objected to the 'wheel' group that would restrict the ability to call 'su' to just the members of 'wheel'. He wanted everyone who somehow obtained the root password to be able to become root.
This is probably the largest reason wheel is not used on Linux. The BSDs still require wheel to become root
In OpenBSD at least, if there are users in the wheel group then this is enforced. If there are no users in the wheel group then anyone who knows the password can become root.
Re: Bcrypt at 25
#50As one of the creators of bcrypt back in 1997, I find it somewhat surprising that, 25 years later, we still rely heavily on passwords. Not that surprising. It's hard to think of any better alternative. Attempts at replacing passwords results in worse user experience or added complexity.
Yeah passwords have persisted because they are conceptually easy for people to understand. 2FA with a code sent by SMS is also easy for anyone with a phone. No apps to install, nothing to set up or manage. Just provide your phone number one time.
So despite all the flaws, it's the least bad thing we've come up with that doesn't cause an explosion of user support issues. Any replacement is going to need to be at least that easy.