91–100 of 184 posts
I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.
This very web-forum was a very big proponent of those politics a few years ago.
> X. Dev/prod parity > Keep development, staging, and production as similar as possible Gets interesting at the seams of software & data environments. If my preprod stack operates independently of my prod stack (due to different internal users), but preprod data stack is best tested on prod data, the seams of these two things imply there should be a separate data stack for both preprod data versus preprod-internal. G…
Earlier quoted context omitted.
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 progra…
I do quibble with the statement that
> unsetenv(3) is probably enough to avoid the actual attack vector
It's not, because it doesn't modify the environment block of the process. Even if you use unsetenv, you're one path-traversal vuln away from folks being able to read all your startup-time secrets out of /proc/self/environ. Similar is true for exploits that can read process memory in small chunks: it takes time and risks detection to e.g. crawl around the stack/heap of who-knows-what-language to find interesting variables, but it's a lot easier to grab whatever's at the top of the stack by address (the env blob, which I think is also unmodified by most unsetenv(3) implementations). Path traversals and small-arbitrary-read exploits aren't exactly uncommon, and environment variables are the wp-admin/admin.php of exploit targets.
That's a quibble; you're broadly right, and that risk's not nearly severe enough to torture your code or bring in caching + encrypting runtime secret stores or whatnot.
I just wish env had been implemented without a /proc view and with reads requiring a cheap syscall rather than memory-residence, you know? Yeah, it's pointless to speculate about, but still seems like an obviously-preferable-in-retrospect road not taken.
"saffron-grade security" is pretty good, too.
Earlier quoted context omitted.
100% this. 1. Keep secrets in a dedicated secrets store. 2. Read directly from the secrets store in application code. There is no environment, there are no environment variables. Yes, even on local.
It's pretty normal to keep secrets in a dedicated secret store, and then have the service launcher inject them from the secret store into the environment.
we now have a secret cache layer api and the app loads secrets securely at time of use from that api. there's also no secret-0 problem because we use IAM auth when calling the cache.
edit: for those wondering, api response time is sub 1ms (rust!)
Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…
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…
Configuration changes also change application behavior, otherwise is it really “config”?
Earlier quoted context omitted.
> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files Teach them to use dotenv. We are moving away from configuration in config files because it is a pain to modify, especially if part of that configuration is secrets. You have to throw everything into your secrets vault of preference, and editing it requires extracting and reuploading the whole th…
My issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is. Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library add…
Earlier quoted context omitted.
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.