Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bcrypt at 25

usenix.org

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Bcrypt at 25

#11

Post by gchamonlive »

throwawaaarrgh wrote: post #4

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 HTT…

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

Re: Bcrypt at 25

#12

Post by paulpauper »

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.

Re: Bcrypt at 25

#13

Post by ilyt »

throwawaaarrgh wrote: post #4

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 HTT…

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

Re: Bcrypt at 25

#14

Post by ilyt »

jwilk wrote: post #8
542458 wrote: post #6

> 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?

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.

soo basically "they are so shit they are no barrier whatsoever"

Re: Bcrypt at 25

#15

Post by c4mpute »

mLuby wrote: post #9
throwawaaarrgh wrote: post #4

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 HTT…

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

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.

Re: Bcrypt at 25

#16

Post by ilyt »

paulpauper wrote: post #12

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.

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

Re: Bcrypt at 25

#17

Post by jmclnx »

c4mpute wrote: post #7
542458 wrote: post #6

> 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?

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

Re: Bcrypt at 25

#18

Post by samtho »

paulpauper wrote: post #12

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.

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

Re: Bcrypt at 25

#19

Post by candiddevmike »

djbusby wrote: post #5
candiddevmike wrote: post #3

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

Is that WASM libsodium that's problematic? Can you expand on the issue?

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.

Re: Bcrypt at 25

#20

Post by qingcharles »

c4mpute wrote: post #7
542458 wrote: post #6

> 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?

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.

"Why do you need a password? What are you hiding?"
Post reply on HN