Hacker News Reader

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

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

So how do developers e.g. add a new field to the User schema if needed for the business? Or customize the login page? Or ...

Now you have a CMS like Wordpress, no longer a library or even framework, which has so many moving parts that is def not "secure by default".

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?

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

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)

That would most likely require an API gateway of sorts to handle the security procedures transparently. Build bare APIs and run them isolated, exposed by a layer that provides security services through composition.

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

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.

Maybe before we die ;)

It would be cool if the challenge could specify the URL of an image to appear in the login dialog.

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

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

Imho WebAuthn is just the next problematic non-solution: Everything you do in WebAuthn you have to build up manually within the already-problematic forms+cookies+serverlogic+javascript stack. You cannot just instruct your webserver to do WebAuthn for /secret and everything works, no, you need tons and tons of code for it to work. Code that will have errors and problems. Code that is lots of complications on top of forms+cookies+serverlogic+javascript.

WebAuthn might solve a problem for the likes of Google and Facebook. But definitely not for the average web developer or server admin. And not for the user of some HTTP-based API. And the problem WebAuthn solves isn't really "we need better Auth", it is rather "we need better customer lock-in". Because the complexity and incompatibility of WebAuthn will just reproduce the debacle that was OpenID, only with the added "bonus" of being coupled to some hardware.

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

This sounds more or like like what factotum (https://9fans.github.io/plan9port/man/man4/factotum.html), from plan9, tried to do