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

51–60 of 78 posts

Re: Bcrypt at 25

#51

Post by tptacek »

Vecr wrote: post #48
tptacek wrote: post #45

Earlier quoted context omitted.

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.

Blake3 is not, in fact, a bit iffy.

Re: Bcrypt at 25

#52

Post by waste_monk »

c4mpute wrote: post #15
mLuby wrote: post #9

Earlier quoted context omitted.

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

>also the browsers never got around to implement any sensible UI (e.g. you cannot log off)

FWIW in firefox you can go to "clear recent history" and then uncheck everything but "active logins". This will wipe out any currently logged in basic auth.

Re: Bcrypt at 25

#53

Post by throwawaaarrgh »

franciscop wrote: post #25
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…

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

> in an unopinionated way IMHO (without prescribing the DB schema, etc)

I'm actually suggesting the most opinionated thing imaginable. Definitely it would need its own schema, database (logical database; you could still put it in the same SQL server instance).

I've implemented this before, it works fine. Basically imagine that your app can only talk to some login system through a command-line tool, and the command like tool deals with the database. You have absolutely no control over the login code or database. You can just run commands and give arguments and get something back. Again, programmers hate it, but it works great and is secure by default.

Re: Bcrypt at 25

#54

Post by throwawaaarrgh »

gchamonlive wrote: post #11
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 achi…

I'm saying we should remove the 'encouragement' and make secure operation the only mode.

When there's a new more secure practice, we should use abstractions that make switching to the new mode as simple as changing some external dependency. The mechanism should be abstracted away into something that isn't code, like how running a program with arguments and stdin isn't reliant on some particular programming language.

Instead let some other, separate program deal with the security-centric work, so if you change from "LDAP authentication" to "OAuth2", the business app doesn't ever need to be updated, and you can just change the configuration for the "login app" that the business app talks to. (This kind of already exists, in forms like the OAuth2 Proxy)

Re: Bcrypt at 25

#55

Post by searealist »

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?

It was an extension of communist ideology. Opening up the means of production to everyone.

Re: Bcrypt at 25

#56

Post by mjec »

c4mpute wrote: post #15
mLuby wrote: post #9

Earlier quoted context omitted.

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

> HTTP got basic auth, which is crap because plaintext password transmission happens...

Plaintext submission happens with HTML forms too. The problem with Basic is the password goes with every request. That means you're exposing a long term credential to a higher risk. We want to exchange the long term credential for a short term one, ideally scope limited. That is far less catastrophic to revoke, and gives you some power of granularity (you can at the very least have some operations prompt for the password again). It also means you can limit risk on the server: only one page has access to the long term credentials, which can be more easily audited, or even hosted on dedicated servers.

WebAuthn has been the real savior here. Real cryptography has always been desirable for this, and removing per-site passwords is honestly just a bonus.

Re: Bcrypt at 25

#57

Post by re-thc »

samtho wrote: post #18
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

> Besides the usual tricks of emailing a magic link

Your email still requires password. Besides making it someone else's problem it doesn't solve the issue of not having a password so all the same.

Re: Bcrypt at 25

#58

Post by re-thc »

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

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.

Re: Bcrypt at 25

#59

Post by nullsense »

sillystuff wrote: post #23
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?

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

That seems naive in the extreme.

Re: Bcrypt at 25

#60

Post by TylerE »

nullsense wrote: post #59
sillystuff wrote: post #23

Earlier quoted context omitted.

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

That seems naive in the extreme.

I mean, it's Stallman. Of course it is. Has anyone who was so wrong about so much ever achieved such celebrity, at least outside of Politics?

It's amazing he didn't destroy the entire movement.

Post reply on HN