34 ms·

Bcrypt at 25

163 points by aa_is_op 3y ago

DamonHD 3y ago
Now following Activ8te on SoundCloud!
- dgacmu 3y ago
  Since this comment seems the be getting down voted, it might benefit from context: Activ8te is Niels Provos (author of this article)'s EDM pseudonym, where he's making music with cyber security themes: > To address this scarcity of talent, I've pursued a very unconventional approach. I've embarked on a new venture as an EDM (Electronic Dance Music) producer under the artist name Activ8te, creating cybersecurity-themed EDM tracks. My goal is to captivate a younger audience and ignite their interest in security topics. Some of my recent tracks, like "Teardrop Falling" and "I Am Tracking You," explore challenging security themes such as denial of service, censorship, and the risks to our privacy posed by sophisticated spyware (Activ8te, 2022). By raising awareness and enthusiasm for the field, I hope to contribute to the expansion of a skilled security professional pipeline.
  - DamonHD 3y ago
    Thanks! As it happens we've now had a pleasant chat in PMs on SC and he has given me a little advice on my home (mainly energy) data -> house music thing! B^>
candiddevmike 3y ago
I'd like to use Argon2 for web stuff but Web Crypto doesn't support it yet (https://github.com/WICG/proposals/issues/59 https://github.com/WICG/proposals/issues/59) and the WASM flavor creates problems with bundling and testing. Stuck with PBKDF2 for now...
- djbusby 3y ago
  Is that WASM libsodium that's problematic? Can you expand on the issue?
  - candiddevmike 3y ago
    It was this WASM library: https://github.com/urbit/argon2-wasm https://github.com/urbit/argon2-wasm. I couldn't get vitest to work with code that imports WASM, and I couldn't get vite to bundle WASM code for web workers.
- jedisct1 3y ago
  An algorithm that requires a ton of memory doesn't really make sense for web applications IMHO. bcrypt and bscrypt are better choices.
  - nabla9 3y ago
    Is 2 KiB really ton of memory?
    - jedisct1 3y ago
      If you use Argon2 with 2 KiB, there's something really wrong with your parameters.
      - nabla9 3y ago
        Argon2 with 2 KiB has more memory hardness than BCRYPT.
  - thayne 3y ago
    It does if your application is a password manager like bitwarden, lastpass, 1password, etc. Or really anything where you need or want client side encryption protected by a passport.
- re-thc 3y ago
  I wonder if it'd get anywhere. There's not enough CPU/memory allocated in a lot of these platforms to make it work e.g. Deno deploy and Cloudflare workers (bundled) has 50ms of CPU time.
throwawaaarrgh 3y ago
It actually wouldn't be that hard to make off the shelf security solutions for free. We just need to take away the developer's choice and force them to integrate with some simple functionality. For example, make a login management framework that is feature-complete and does not require the dev to implement their own "hooks" into its methods. Instead use a config file to tell the framework how to work (expose this HTTP endpoint, use this data backend, etc) and just send it data in the way it expects, and have it respond with booleans. I assume devs might hate this, but it does give the business what it needs without relying on devs to implement it correctly (or have to wait on them to do it). There are some overcomplicated examples of this already (keycloak) but we could make simpler things too that are secure, and more of them. Particularly I think SQL frameworks, REST API frameworks, HTTP daemons, container image builders, Cloud authentication methods, Git repositories, etc could easily implement stronger guardrails to force development to be secure by default. The fact that most Cloud software today still tells devs to give it a static infinitely-lived authentication key is absurd. That just should not be possible; take that shit out of the software. We can do way better.
- mLuby 3y ago
  > We just need to take away the developer's choice and force them to integrate Who's we? Who are they integrating with? A protocol? A business? A government? This has been tried in a multitude of ways. There's always a bit too much friction or cost.
  - c4mpute 3y ago
    Also, all the standards were crap. HTTP got basic auth, which is crap because plaintext password transmission happens, also the browsers never got around to implement any sensible UI (e.g. you cannot log off). Then it got digest auth, which at least wasn't plaintext in transmission, but required plaintext password storage on the server. Then came negotiate, which only worked with some proprietary products, had even worse UI and was unusable outside a company's internal net. Alongside that, there was HTTPS client auth, where, instead of fixing known problems, standards devolved into "sorry, we don't support that anymore". Also, the UI was crap. Alongside that, there are homegrown methods using web forms, cookies, a lot of spit and maybe some javascript, which everyone uses atm. Everyone rolls their own, because over decades, standard bodies couldn't get their shit together. Also, everyone suffered from the corresponding attacks on all the weak and broken homegrown crap out there. There is friction and cost, but those come from a lack of trying and a lack of giving a fuck by the people building web browsers, web servers and web standards. They basically declared the problem solved after the invention of cookies.
542458 3y ago
> This came over the strenuous objections of Richard Stallman who famously tried to resist the introduction of passwords at MIT in the 1970s (Levy, 1984). Out of curiosity, what was his competing proposal?
- c4mpute 3y ago
  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.
  - jmclnx 3y ago
    This is probably the largest reason wheel is not used on Linux. The BSDs still require wheel to become root
    - SoftTalker 3y ago
      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.
  - qingcharles 3y ago
    "Why do you need a password? What are you hiding?"
    - deleted 3y ago
      [deleted]
- jwilk 3y ago
  https://en.wikipedia.org/wiki/Richard_Stallman#Harvard_University_and_MIT https://en.wikipedia.org/wiki/Richard_Stallman#Harvard_Unive... > Stallman found a way to decrypt the passwords and sent users messages containing their decoded password, with a suggestion to change it to the empty string (that is, no password) instead, to re-enable anonymous access to the systems.
paulpauper 3y ago
As 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.
- ilyt 3y ago
  Hardware tokens ain't bad when done right but a lot of added complexity and price. We use Yubikeys for SSH and it is pretty flawless experience once set up
- samtho 3y ago
  Besides the usual tricks of emailing a magic link or using your 2FA as a super login code, I can see either some sort of hardware token (cost prohibitive for most people) or more likely something like SQRL[0][1]. [0]: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm [1]: https://en.m.wikipedia.org/wiki/SQRL https://en.m.wikipedia.org/wiki/SQRL
  - qingcharles 3y ago
    I was incapacitated for many years and my phone plan lapsed, so I lost the number. My email account lapsed and so did all my domains, so I lost access to all my email addresses. I now have about 1000 online accounts that I have no way to access because there is no way to authenticate myself. 2FA can be a real pain in some situations, even though I still advise everyone I know to enable it on their most sensitive accounts as the alternatives aren't great.
    - samtho 3y ago
      What you went through must have been really awful, I’m sorry that happened to you. That being said, this sounds like a rare occurrence. I’m sure since then you’ve created some contingency plan especially if there is a potential for a repeat. This actually highlights one of my fears of everything being tied to a phone number because you can never truly own it and it can be canceled or you could be sim-swapped.
jedisct1 3y ago
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 https://github.com/Sc00bz/bscrypt
- indeyets 3y ago
  Is it verified, peer-reviewed? I can't find much about it
  - tptacek 3y ago
    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.
    - Vecr 3y ago
      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.
      - tptacek 3y ago
        Blake3 is not, in fact, a bit iffy.
        Vecr 3y ago
        Sure, but the tree structure is "made up" and has had less scrutiny than something than SHA2 SHA384 for example. I use it, but that's where my border line is.
- deleted 3y ago
  [deleted]
deepzn 3y ago
Wired article talking with Provos - https://www.wired.com/story/bcrypt-password-hashing-25-years/ https://www.wired.com/story/bcrypt-password-hashing-25-years...
WeylandYutani 3y ago
Due to my mental illness I always forget my passwords. It annoys me because frankly aside from my email and bank account IDGAF about the rest of my online identity. But no I need to have a 12 character password for the supermarket app!
- lucakiebel 3y ago
  Have you tried using a password manager?
throw0101b 3y ago
See also "A Popular Password Hashing Algorithm Starts Its Long Goodbye": * https://www.wired.com/story/bcrypt-password-hashing-25-years/ https://www.wired.com/story/bcrypt-password-hashing-25-years...
- tptacek 3y ago
  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.
  - ycombinete 3y ago
    2023 will be the year of the password-less Linux desktop
e4m2 3y ago
bcrypt 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) This has the following caveats: 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.
- NavinF 3y ago
  > 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
- tptacek 3y ago
  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.
djee 3y ago
Overlooked in the (excellent) article and interesting for cracking bcrypt passwords: FPGAs, see e.g. <https://scatteredsecrets.medium.com/bcrypt-password-cracking-extremely-slow-not-if-you-are-using-hundreds-of-fpgas-7ae42e3272f6 https://scatteredsecrets.medium.com/bcrypt-password-cracking...>.

Bcrypt at 25

163 points by aa_is_op 3y ago

DamonHD 3y ago

Now following Activ8te on SoundCloud!

dgacmu 3y ago
Since this comment seems the be getting down voted, it might benefit from context: Activ8te is Niels Provos (author of this article)'s EDM pseudonym, where he's making music with cyber security themes: > To address this scarcity of talent, I've pursued a very unconventional approach. I've embarked on a new venture as an EDM (Electronic Dance Music) producer under the artist name Activ8te, creating cybersecurity-themed EDM tracks. My goal is to captivate a younger audience and ignite their interest in security topics. Some of my recent tracks, like "Teardrop Falling" and "I Am Tracking You," explore challenging security themes such as denial of service, censorship, and the risks to our privacy posed by sophisticated spyware (Activ8te, 2022). By raising awareness and enthusiasm for the field, I hope to contribute to the expansion of a skilled security professional pipeline.
- DamonHD 3y ago
  Thanks! As it happens we've now had a pleasant chat in PMs on SC and he has given me a little advice on my home (mainly energy) data -> house music thing! B^>

candiddevmike 3y ago

I'd like to use Argon2 for web stuff but Web Crypto doesn't support it yet (https://github.com/WICG/proposals/issues/59 https://github.com/WICG/proposals/issues/59) and the WASM flavor creates problems with bundling and testing. Stuck with PBKDF2 for now...

djbusby 3y ago
Is that WASM libsodium that's problematic? Can you expand on the issue?
- candiddevmike 3y ago
  It was this WASM library: https://github.com/urbit/argon2-wasm https://github.com/urbit/argon2-wasm. I couldn't get vitest to work with code that imports WASM, and I couldn't get vite to bundle WASM code for web workers.
jedisct1 3y ago
An algorithm that requires a ton of memory doesn't really make sense for web applications IMHO. bcrypt and bscrypt are better choices.
- nabla9 3y ago
  Is 2 KiB really ton of memory?
  - jedisct1 3y ago
    If you use Argon2 with 2 KiB, there's something really wrong with your parameters.
    - nabla9 3y ago
      Argon2 with 2 KiB has more memory hardness than BCRYPT.
- thayne 3y ago
  It does if your application is a password manager like bitwarden, lastpass, 1password, etc. Or really anything where you need or want client side encryption protected by a passport.
re-thc 3y ago
I wonder if it'd get anywhere. There's not enough CPU/memory allocated in a lot of these platforms to make it work e.g. Deno deploy and Cloudflare workers (bundled) has 50ms of CPU time.

throwawaaarrgh 3y ago

It actually wouldn't be that hard to make off the shelf security solutions for free. We just need to take away the developer's choice and force them to integrate with some simple functionality. For example, make a login management framework that is feature-complete and does not require the dev to implement their own "hooks" into its methods. Instead use a config file to tell the framework how to work (expose this HTTP endpoint, use this data backend, etc) and just send it data in the way it expects, and have it respond with booleans. I assume devs might hate this, but it does give the business what it needs without relying on devs to implement it correctly (or have to wait on them to do it). There are some overcomplicated examples of this already (keycloak) but we could make simpler things too that are secure, and more of them. Particularly I think SQL frameworks, REST API frameworks, HTTP daemons, container image builders, Cloud authentication methods, Git repositories, etc could easily implement stronger guardrails to force development to be secure by default. The fact that most Cloud software today still tells devs to give it a static infinitely-lived authentication key is absurd. That just should not be possible; take that shit out of the software. We can do way better.

mLuby 3y ago
> We just need to take away the developer's choice and force them to integrate Who's we? Who are they integrating with? A protocol? A business? A government? This has been tried in a multitude of ways. There's always a bit too much friction or cost.
- c4mpute 3y ago
  Also, all the standards were crap. HTTP got basic auth, which is crap because plaintext password transmission happens, also the browsers never got around to implement any sensible UI (e.g. you cannot log off). Then it got digest auth, which at least wasn't plaintext in transmission, but required plaintext password storage on the server. Then came negotiate, which only worked with some proprietary products, had even worse UI and was unusable outside a company's internal net. Alongside that, there was HTTPS client auth, where, instead of fixing known problems, standards devolved into "sorry, we don't support that anymore". Also, the UI was crap. Alongside that, there are homegrown methods using web forms, cookies, a lot of spit and maybe some javascript, which everyone uses atm. Everyone rolls their own, because over decades, standard bodies couldn't get their shit together. Also, everyone suffered from the corresponding attacks on all the weak and broken homegrown crap out there. There is friction and cost, but those come from a lack of trying and a lack of giving a fuck by the people building web browsers, web servers and web standards. They basically declared the problem solved after the invention of cookies.

542458 3y ago

> This came over the strenuous objections of Richard Stallman who famously tried to resist the introduction of passwords at MIT in the 1970s (Levy, 1984). Out of curiosity, what was his competing proposal?

c4mpute 3y ago
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.
- jmclnx 3y ago
  This is probably the largest reason wheel is not used on Linux. The BSDs still require wheel to become root
  - SoftTalker 3y ago
    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.
- qingcharles 3y ago
  "Why do you need a password? What are you hiding?"
  - deleted 3y ago
    [deleted]
jwilk 3y ago
https://en.wikipedia.org/wiki/Richard_Stallman#Harvard_University_and_MIT https://en.wikipedia.org/wiki/Richard_Stallman#Harvard_Unive... > Stallman found a way to decrypt the passwords and sent users messages containing their decoded password, with a suggestion to change it to the empty string (that is, no password) instead, to re-enable anonymous access to the systems.

paulpauper 3y ago

As 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.

ilyt 3y ago
Hardware tokens ain't bad when done right but a lot of added complexity and price. We use Yubikeys for SSH and it is pretty flawless experience once set up
samtho 3y ago
Besides the usual tricks of emailing a magic link or using your 2FA as a super login code, I can see either some sort of hardware token (cost prohibitive for most people) or more likely something like SQRL[0][1]. [0]: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm [1]: https://en.m.wikipedia.org/wiki/SQRL https://en.m.wikipedia.org/wiki/SQRL
- qingcharles 3y ago
  I was incapacitated for many years and my phone plan lapsed, so I lost the number. My email account lapsed and so did all my domains, so I lost access to all my email addresses. I now have about 1000 online accounts that I have no way to access because there is no way to authenticate myself. 2FA can be a real pain in some situations, even though I still advise everyone I know to enable it on their most sensitive accounts as the alternatives aren't great.
  - samtho 3y ago
    What you went through must have been really awful, I’m sorry that happened to you. That being said, this sounds like a rare occurrence. I’m sure since then you’ve created some contingency plan especially if there is a potential for a repeat. This actually highlights one of my fears of everything being tied to a phone number because you can never truly own it and it can be canceled or you could be sim-swapped.

jedisct1 3y ago

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 https://github.com/Sc00bz/bscrypt

indeyets 3y ago
Is it verified, peer-reviewed? I can't find much about it
- tptacek 3y ago
  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.
  - Vecr 3y ago
    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.
    - tptacek 3y ago
      Blake3 is not, in fact, a bit iffy.
      - Vecr 3y ago
        Sure, but the tree structure is "made up" and has had less scrutiny than something than SHA2 SHA384 for example. I use it, but that's where my border line is.
deleted 3y ago
[deleted]

deepzn 3y ago

Wired article talking with Provos - https://www.wired.com/story/bcrypt-password-hashing-25-years/ https://www.wired.com/story/bcrypt-password-hashing-25-years...

WeylandYutani 3y ago

Due to my mental illness I always forget my passwords. It annoys me because frankly aside from my email and bank account IDGAF about the rest of my online identity. But no I need to have a 12 character password for the supermarket app!

lucakiebel 3y ago
Have you tried using a password manager?

throw0101b 3y ago

See also "A Popular Password Hashing Algorithm Starts Its Long Goodbye": * https://www.wired.com/story/bcrypt-password-hashing-25-years/ https://www.wired.com/story/bcrypt-password-hashing-25-years...

tptacek 3y ago
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.
- ycombinete 3y ago
  2023 will be the year of the password-less Linux desktop

e4m2 3y ago

bcrypt 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) This has the following caveats: 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.

NavinF 3y ago
> 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
tptacek 3y ago
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.

djee 3y ago

Overlooked in the (excellent) article and interesting for cracking bcrypt passwords: FPGAs, see e.g. <https://scatteredsecrets.medium.com/bcrypt-password-cracking-extremely-slow-not-if-you-are-using-hundreds-of-fpgas-7ae42e3272f6 https://scatteredsecrets.medium.com/bcrypt-password-cracking...>.