Bcrypt at 25
usenix.org
Bcrypt at 25
1–10 of 78 posts
Re: Bcrypt at 25
#2Now following Activ8te on SoundCloud!
Re: Bcrypt at 25
#3I'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...
Re: Bcrypt at 25
#4It 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.
Re: Bcrypt at 25
#5I'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?
Re: Bcrypt at 25
#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?
Re: Bcrypt at 25
#7> 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.
Re: Bcrypt at 25
#8> 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.
Re: Bcrypt at 25
#9It 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.
Re: Bcrypt at 25
#10It 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 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?