2 ms·

> 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

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

throwawaaarrgh 3y ago
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)
- gchamonlive 3y ago
  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.

throwawaaarrgh 3y ago

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)

gchamonlive 3y ago
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.