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

The Twelve-Factor App (2025)

12factor.net

Post reply on HN
Print view View original

81–90 of 184 posts

Re: The Twelve-Factor App (2025)

#81

Post by nailer »

HHad3 wrote: post #45
jt2190 wrote: post #28

Earlier quoted context omitted.

The unwritten assumption in 12 Factor is: the environment is secure . For example, a production system should always have a secure means of setting environment variables. Said another way: If a random dev can change an environment variable in production either directly by logging in or indirectly by pushing code then there is something very very wrong. If the dev is pushing code to production they should not simultan…

Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident. The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.

> you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident.

Game over already if anyone can run commands or arbitrary code. Not using the environment won't help you.

Re: The Twelve-Factor App (2025)

#82

Post by tptacek »

abofh wrote: post #75
tptacek wrote: post #65

Earlier quoted context omitted.

It's not my intuition that materializing secrets to files is a better way to protect them than just injecting them into the environment, where they don't persist.

Dev/shm is used to materialize them, and then you have the ability to isolate the downstream code you might use from accessing it by dropping permissions or sandboxing it away from a file. You cannot really hide your environment from anything in process, since it's such a low level construct. Thus it's easier to leak environment unintentionally, leaking file contents takes effort.

Not at all clear why this is a better setup than a launcher shim that pulls secrets from a secret store and injects them into the environment as the program launches --- which is a pretty normal shape for these things to take.

I guess you could be thinking "subprocess inheritance" as a downside? But subprocesses often need secrets, and if you arrange for that with the filesystem you have the same problem. And, of course, files leak all the time.

More to the point, though: none of this has anything to do with whether you should add secrets to your .bashrc or whatever, which is the argument I'm seeing on the thread.

Re: The Twelve-Factor App (2025)

#84

Post by tptacek »

zbentley wrote: post #56
nebezb wrote: post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

Firmly agree. A lot of sibling comments are talking about environment mutation (which does have issues); I want to talk about environment read access. The environment is a standard, locate-able, read-only at runtime k/v store in every process. That makes it an incredibly juicy target for exploits. There are tons of remote exploits well short of RCE which can access all or part of a server process's environment. If th…

I feel like people just think they should be doing all sorts of complicated stuff, and if they're not, they're somehow slacking off on security. You used to see the same thing with password hashes where people would write paragraphs about how they have salts and peppers and spices, passionately arguing for the necessity of each.

At the point where you're encrypting secrets in resident memory in a normal server program, you have gone fully into saffron-grade security. If you're worried about leaking secrets in your environment, overwrite the environment variable data and be done with it. In reality, if this is a real concern, unsetenv(3) is probably enough to avoid the actual attack vector --- a vulnerability where you leak environment variables qua environment variables (because you shell out or something).

Whatever vulnerability you're positing that leaks a secret out of arbitrary resident memory also leaks whatever secret you'd use to encrypt, and now you're not building a security system, you're building a DRM scheme. Don't let me yuck your yum on that, but: not a good ROI for security.

Re: The Twelve-Factor App (2025)

#85

Post by modeless »

xander_north wrote: post #24
browningstreet wrote: post #2

I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.

Okay so this may sound odd but this is literally my whole life right now... Can you explain why do you feel MFA is painful/unsustainable? How would you fix it?

Personally I hate when I use a passkey but then still get hit with an SMS second factor step. A passkey should be enough, unless I'm changing my recovery email or withdrawing a million dollars or something. Also there's still a lot of really bad UX around passkeys, both by browser/OS vendors and by individual apps, and unimplemented features like sharing.

Passkeys are the right thing but they need more work.

Re: The Twelve-Factor App (2025)

#87

Post by lxe »

I know that all of this is super relevant, but it's extremely aspirational, and I can pick apart pretty much every one of these factors on how it doesn't fully hold up when it comes to the reality of production applications.

Re: The Twelve-Factor App (2025)

#88

Post by jcgl »

jt2190 wrote: post #28
nebezb wrote: post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

The unwritten assumption in 12 Factor is: the environment is secure . For example, a production system should always have a secure means of setting environment variables. Said another way: If a random dev can change an environment variable in production either directly by logging in or indirectly by pushing code then there is something very very wrong. If the dev is pushing code to production they should not simultan…

Adding on to what others say about printenv, various diagnostic tools (e.g. crash reporting stuff) will capture the environment. Env vars are just categorically so easy to accidentally leak that it can’t even be classed as an insecurity.

Re: The Twelve-Factor App (2025)

#89

Post by xorcist »

imglorp wrote: post #53

Good best practices, mostly, but I feel the 12FA model totally punted on state by defining it out of scope: "state is over there in that external service, three-monkeys-emoji". Yeah but sometimes state is the entire point and you need to manage it yourself, and then some of your processes must be 9 or 10 factor as a result.

State is always the entire point.

Re: The Twelve-Factor App (2025)

#90

Post by Silasdev »

lxe wrote: post #87

I know that all of this is super relevant, but it's extremely aspirational, and I can pick apart pretty much every one of these factors on how it doesn't fully hold up when it comes to the reality of production applications.

Of course you can, but it's still a really great collection of good practices that lead you to a better place than if you didn't to do any of it.
Post reply on HN