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

71–80 of 184 posts

Re: The Twelve-Factor App (2025)

#71

Post by browningstreet »

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?

Google pushes "password" down 2 layers of their interface. If you really want to use a password to authenticate, it's not always a first class citizen.

Both Google and Microsoft call their apps Authenticator, so two identically named apps on my iPhone distinguishable only by logo.

Furthermore, if you login to 20 things a day (which I do), the codes are going to these apps, SMS, and email. Each different.. so if I'm on my Linux box, my Watch doesn't really help. If I leave my phone in the other room, I can't use the apps to get the code without going to the other room. If multi-tasking is expensive for the brain and attention, MFA is the computing surface equivalent.

You may have built a great MFA workflow, but I have to live with 3-10 variations of workflows all day long, including puzzles. And it's more aggravating when I have to MFA to your service to get my information. My machine is in my house and nobody's been in my house but every_single_login requires me to pretend that in every moment of every day someone may have stolen my laptop and my finger.

My work machine will let me auth with my fingerprint, but the typical enterprise integration of all the things means I still have to click through 3-4 screens to get to where the fingerprint is accepted.

Services and APIs don't MFA.. they have keys and other restrictions for seamlessness. Where's the seamlessness solution for humans?

Passkeys are cool, but they're not ubiquitous enough yet, and the interface between desktop and mobile (even using 1Password for universal passkeys) wouldn't qualify as solved in my book.

MFA as whack-a-mole UI sucks.

Re: The Twelve-Factor App (2025)

#72

Post by NewJazz »

tptacek wrote: post #65
HHad3 wrote: post #45

Earlier quoted context omitted.

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.

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.

The env is technically still kind of a file on linux at least (through /proc).

Sometimes I feel like stdin or an unlinked memory mapped file might be the best location for this stuff. Wish Linux had a cloexec+1 option, where an fd is closed after two execs, so you can set up a child process for success.

Re: The Twelve-Factor App (2025)

#73

Post by tptacek »

NewJazz wrote: post #72
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.

The env is technically still kind of a file on linux at least (through /proc). Sometimes I feel like stdin or an unlinked memory mapped file might be the best location for this stuff. Wish Linux had a cloexec+1 option, where an fd is closed after two execs, so you can set up a child process for success.

Only in the sense that everything is technically a kind of a file given access to proc.

Re: The Twelve-Factor App (2025)

#74

Post by zuuna »

JoshTriplett wrote: post #51
VeninVidiaVicii wrote: post #15

Earlier quoted context omitted.

Every time I leave my phone in the other room to “finally get some work done”, please enter this goddamn number we sent to your SMS, and I close my laptop.

The most obnoxious aspect of that: I specifically have my texts accessible on my laptop, but some 2fa authentication texts get blocked via that mechanism in favor of a message saying "look at this message on your phone".

Gets worse. A lot of accounts were set up by my boss so it's all his 2FA. Then some of these require the phone to scan a QR-Code. We work remotely.

Re: The Twelve-Factor App (2025)

#75

Post by abofh »

tptacek wrote: post #65
HHad3 wrote: post #45

Earlier quoted context omitted.

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.

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.

Re: The Twelve-Factor App (2025)

#76

Post by solarengineer »

tptacek wrote: post #65
HHad3 wrote: post #45

Earlier quoted context omitted.

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.

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.

(Edit: I need to read up on this better)

Re: The Twelve-Factor App (2025)

#77

Post by preommr »

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

Disagree, partially.

Buy-into storing credentials into environment variables.

Then, and this is important - MANAGE YOUR ENVIRONMENTS.

You shouldn't have prod level s3, or aws creds accessible openly in your environment. If someone can steal those values, they can steal the code, and pretty much everything else. This is very bad.

For prod (and possibly staging), use a lib that loads in values securely from an actual secrets service.

Re: The Twelve-Factor App (2025)

#79

Post by crote »

tptacek wrote: post #65
HHad3 wrote: post #45

Earlier quoted context omitted.

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.

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.

It doesn't need to be a traditional file. You can pass it as essentially a read-once file by using stdin. Depending on your desire for modernity, similar behavior can be obtained by leaving a file handle open for the exec-ed process to inherit, via a Unix socket, or even a lightweight TCP daemon.
Post reply on HN