[HN Gopher] Bcrypt at 25
___________________________________________________________________
Bcrypt at 25
Author : aa_is_op
Score : 112 points
Date : 2023-05-28 14:57 UTC (8 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| jedisct1 wrote:
| 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
| indeyets wrote:
| Is it verified, peer-reviewed? I can't find much about it
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| Blake3 is not, in fact, a bit iffy.
| [deleted]
| throw0101b wrote:
| See also "A Popular Password Hashing Algorithm Starts Its Long
| Goodbye":
|
| * https://www.wired.com/story/bcrypt-password-hashing-25-years...
| tptacek wrote:
| 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 wrote:
| 2023 will be the year of the password-less Linux desktop
| DamonHD wrote:
| Now following Activ8te on SoundCloud!
| dgacmu wrote:
| 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 wrote:
| 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^>
| WeylandYutani wrote:
| 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 wrote:
| Have you tried using a password manager?
| e4m2 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| candiddevmike wrote:
| I'd like to use Argon2 for web stuff but Web Crypto doesn't
| support it yet (https://github.com/WICG/proposals/issues/59) and
| the WASM flavor creates problems with bundling and testing. Stuck
| with PBKDF2 for now...
| jedisct1 wrote:
| An algorithm that requires a ton of memory doesn't really make
| sense for web applications IMHO. bcrypt and bscrypt are better
| choices.
| thayne wrote:
| 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.
| nabla9 wrote:
| Is 2 KiB really ton of memory?
| jedisct1 wrote:
| If you use Argon2 with 2 KiB, there's something really
| wrong with your parameters.
| djbusby wrote:
| Is that WASM libsodium that's problematic? Can you expand on
| the issue?
| candiddevmike wrote:
| It was this WASM library:
| 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.
| paulpauper wrote:
| _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.
| SoftTalker wrote:
| 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.
| ilyt wrote:
| 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 wrote:
| 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
|
| [1]: https://en.m.wikipedia.org/wiki/SQRL
| qingcharles wrote:
| 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 wrote:
| 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.
| throwawaaarrgh wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| singpolyma3 wrote:
| Since everything is TLS now, basic auth no longer transmits
| in the clear. But I agree browser vendors have refused to
| bother putting in even the bare minimum of effort for
| years. I've been subscribed to the firefox ticket to allow
| http auth logout for my entire adult life.
| ape4 wrote:
| Maybe before we die ;)
|
| It would be cool if the challenge could specify the URL
| of an image to appear in the login dialog.
| franciscop wrote:
| > does not require the dev to implement their own "hooks" into
| its methods
|
| > tell the framework how to work [...] and just send it data in
| the way it expects
|
| What is that, if not also "hooks"? I've long thought about this
| and tried many different solutions, and there's only 2 sane
| points to implement a library/framework like this in an
| unopinionated way IMHO (without prescribing the DB schema,
| etc): you provide a library like passport.js with lower level
| hooks (data hashing, vendor connections, etc), or you provide a
| framework integration with higher level hooks (API, DB schemas,
| etc); the problem with the higher level hooks is that you'll
| need many more hooks, with the only advantage that the dev
| might need to write a bit less code overall.
|
| As an example, let's see password recovery. With lower level
| hooks, the dev writes the recover page fully, the API endpoint
| and backend for it, and somewhere in this backend has a small
| integration with the hashing the new password; which then the
| dev saves in the DB. The dev has to do all of this, but in
| exchange the hook integration is just "hash the password".
|
| However for a higher-level (let's assume a JSON API)
| integration as you seem to suggest, now you need to use the
| hooks from the front-end to the custom API, two endpoints that
| hopefully work as expected. And then you need to use the hooks
| to connect from the data generation to the DB, again at least
| 3-4 hooks to check for the valid user, check for duplicated
| password (maybe?), save the new password. And error handling
| here and to the front-end, which is going to be a monster.
|
| (or an opinionated way like Firebase where you bring the whole
| house, but let's leave that for another post)
| di4na wrote:
| The fact you think it is possible, which runs against every
| experience we have had in this domain the past few decades,
| combined with the philosophical and mathematical underpinning
| of software itself running against what you describe too,
| should maybe give pause to re-evaluate the claim?
| gchamonlive wrote:
| > The fact that most Cloud software today still tells devs to
| give it a static infinitely-lived authentication key is absurd.
| We can do way better.
|
| I could be misunderstanding your point, but cloud software is
| encouraged to rely on infrastructure introspection and role
| inheritance to achieve machine-to-machine authentication. There
| is also the problem when authenticating between user owned
| services, which can be achieved with services like Consul.
| Keycloak as far as I understand solves a lot of human-to-
| machine authentication scenarios.
|
| In any case, I agree with the point that developing a secure
| application is hard enough that people might get it wrong even
| when actually trying to build it right. The development tools
| should induce secure development by default, but I believe the
| many particularities and use cases make it a hard problem to
| solve in a simple way. My point is that companies develop
| vulnerable application not because they want to in many cases,
| but because there is no right, clear, unabiguous way to do so
| that fits their particular use case.
| ilyt wrote:
| > 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.
|
| A lot of cloud software doesn't allow you to create the keys
| automatically in the first place.
|
| Ideally only component with persistent key would be one that
| distributes temporary keys to the rest of the components but
| that's usually pretty complicated.
| deepzn wrote:
| Wired article talking with Provos -
| https://www.wired.com/story/bcrypt-password-hashing-25-years...
| 542458 wrote:
| > 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 wrote:
| 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.
| qingcharles wrote:
| "Why do you need a password? What are you hiding?"
| [deleted]
| jmclnx wrote:
| This is probably the largest reason wheel is not used on
| Linux. The BSDs still require wheel to become root
| SoftTalker wrote:
| 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.
| jwilk wrote:
| 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._
| ilyt wrote:
| soo basically "they are so shit they are no barrier
| whatsoever"
| sillystuff wrote:
| Background to his desire for open (non locked down) systems
| (covers the period when the MIT AI lab went from the completely
| open in-house developed ITS to a proprietary Digital system):
|
| https://www.gnu.org/philosophy/stallman-kth.en.html
|
| "...But that machine wasn't designed also to support the
| phenomenon called "tourism." Now "tourism" is a very old
| tradition at the AI lab, that went along with our other forms
| of anarchy, and that was that we'd let outsiders come and use
| the machine. Now in the days where anybody could walk up to the
| machine and log in as anything he pleased this was automatic:
| if you came and visited, you could log in and you could work.
| Later on we formalized this a little bit, as an accepted
| tradition specially when the Arpanet began and people started
| connecting to our machines from all over the country. Now what
| we'd hope for was that these people would actually learn to
| program and they would start changing the operating system. If
| you say this to the system manager anywhere else he'd be
| horrified. If you'd suggest that any outsider might use the
| machine, he'll say "But what if he starts changing our system
| programs?" But for us, when an outsider started to change the
| system programs, that meant he was showing a real interest in
| becoming a contributing member of the community. We would
| always encourage them to do this..."
| gduchgdjv wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-05-28 23:00 UTC)