4 ms·

Show HN: Dotenv Mask Editor: No more embarrassing screen leaks of your .env

28 points by xinbenlv 8mo ago

Hi HN, I built this because I often work in coworking spaces or do screen sharing, and I've always had this fear of accidentally flashing my .env file with production secrets to the whole room (or recording). It’s a simple VS Code extension that opens .env files in a custom grid editor. It automatically masks any value longer than 6 characters so I can safely open the file to check keys without exposing the actual secrets. It runs 100% locally with zero dependencies (I know how sensitive these files are). It just reads the file, renders the grid, and saves it back as standard text. It's open source (MIT) and I'd love any feedback on the masking logic or other features that would make it safer to use. Marketplace: https://marketplace.visualstudio.com/items?itemName=xinbenlv.dotenv-mask-editor https://marketplace.visualstudio.com/items?itemName=xinbenlv... Github https://github.com/xinbenlv/dotenv-mask-editor https://github.com/xinbenlv/dotenv-mask-editor

theozero 8mo ago
Better than masking them in a file, get them out of the file entirely! Pull them declaratively instead - https://varlock.dev https://varlock.dev This tool also redacts from your logs if working in js.
- xinbenlv 8mo ago
  [dead]
  - nonethewiser 8mo ago
    Bravo Founder and CEO of Namefi, but the DNS seems to resolve just fine. Do you understand the DNS space? Perhaps you could find out more using this little side project I've been working on: https://www.google.com/ https://www.google.com/.
    - theozero 8mo ago
      yeah for our DNS we use a little provider called... Cloudflare. But hey some tokenized crypto dns provider is probably much more reliable! lol
      - xinbenlv 8mo ago
        Exactly, exactly
    - xinbenlv 8mo ago
      Haha thanks my friend, well said.
- verdverm 8mo ago
  This appears to be the only comment you make on HN https://news.ycombinator.com/threads?id=theozero https://news.ycombinator.com/threads?id=theozero Using HN less like a marketing platform would be appreciated
- NewJazz 8mo ago
  What does this offer that a scriptlet that sets the envvars doesn't?
svgeek 8mo ago
OMG,I wish I had this years ago!
- xinbenlv 8mo ago
  Thanks, glad you liked it!
__MatrixMan__ 8mo ago
I recently made this as a component in a larger project https://gist.github.com/MatrixManAtYrService/7fc7fb05474d9717da02d0a7a8be7ca5 https://gist.github.com/MatrixManAtYrService/7fc7fb05474d971... The idea is that even if you can't see the full data for some reason (space constraints, in my case), different values will appear styled differently even if the non-hidden characters don't differ. I'm not sure how easy/hard vscode makes this, bit it might be fun to use a hash of the secret (salted by that character's index) to determine the back/foreground colors of the *'s That way even though you can't see the secret, you can tell that it has changed. Also you're in a position to notice if two hidden secrets are the same (this might clue the user into a mistake, like if they didn't actually copy what they think they copied and are instead pasting the previous thing.
dietr1ch 8mo ago
> I've always had this fear of accidentally flashing my .env file with production secrets to the whole room (or recording). Can't you just intersperse entries with multiple-screens-worth of blank lines, or add noisy variables? I'm thinking that 120 blank lines at the beginning and the end might be enough though, no need to make the file really hard to use.
- xinbenlv 8mo ago
  That's a good idea too, thanks for the suggestion
  - dietr1ch 8mo ago
    Also, now that I think about it you could source the super secret stuff from a second file and keep the .env file publicly readable and available for quick edits while streaming
esperent 8mo ago
I recently got a phone with a high zoom level - once you factor in digital zooming it's 20x. The photo quality at that zoom level is trash, but it absolutely could be used to read text from people's laptop screens from across a big room, or even another building through a window. Of course, real cameras have always had this kind of zoom level. The difference is that now, someone could appear to be browsing on their phone from very far away, but actually be reading text on your laptop screen. It's much more likely they'll be looking for credit card details or something like that rather than .env secrets. But I guess it's better safe than sorry if you frequently work in a public, tech focused environment like a big coworking space. We're talking someone sitting with their phone 50 meters away from you being able to read text on your laptop screen. That's about the distance where a person with good vision will struggle to recognize faces.
- verdverm 8mo ago
  Would they need something to help with stabilization at that zoom and distance?
  - canadiantim 8mo ago
    A selfie tripod
  - esperent 8mo ago
    Like sitting at a table and resting their phone on it, sure.
globular-toast 8mo ago
Why would you have "production secrets" in a .env file in the first place? I feel like that's the real problem here.
- deleted 8mo ago
  [deleted]
- xinbenlv 8mo ago
  We use infiscial and other mechanism but hey, wouldn't it be nice to have one less square inch of attack surface?
  - globular-toast 8mo ago
    Why not have one less square mile of attack surface by not having secrets in a .env file in the first place? What are people doing that requires something like this?
    - pjjpo 8mo ago
      I think it's common to have dev not production secrets there, and am reading the blurb about production secrets as non-local secrets. Even dev keys are a pain if they get leaked. The idea seems nice with a simple yet effective implementation. While I think I currently have a shell script syntax highlight plugin reading env files, it's definitely overkill. Now if only this could protect from random npm packages reading your env files...
      - dissent 8mo ago
        This implies there's some kind of shared resource out there on the network that your devs are developing on. Why not make all these resources part of your local dev stack, served on localhost, and use dummy credentials? You can even commit them because they're not sensitive.
        pjjpo 8mo ago
electromech 8mo ago
or, don't put secrets in .env files...
ReluctantLaser 8mo ago
I feel I see these solutions somewhat often, but you can execute a command and use that as a value. To me, I'm not sure why people aren't calling their secret store as part of it. I use direnv mostly, but seems `.env` supports the same thing. e.g: MY_SECRET=$(pass show path/to/my/secret) Of course substitute that for Vault/SSM/whatever. There are other solutions to this problem too, but I show this to people as there's so little friction to using it. As for the solution itself, we shouldn't really be storing secrets as plain text wherever we can help it. Masking them feels like a kludge.
legitimate_key 8mo ago
Congrats on the launch! This resonates - I've dealt with the "accidentally exposed credentials during a demo" problem a lot. The .env file is one of the most common culprits, but I've found the problem extends beyond just one file type. What I've learned: The broader challenge: - .env files in code editors - Config files in various formats (YAML, JSON, TOML) - Database GUIs (showing connection strings, table data) - API tools (Postman, Insomnia showing auth tokens) - Browser tabs (logged into admin panels, showing URLs with tokens) - Terminal windows (commands with API keys) - Slack/email windows (messages with sensitive info) Most solutions are file-type specific or app-specific. But during a screen share, the sensitivity context switches constantly - one moment you're in VS Code, next you're in a browser, then Postman, then back to the terminal. How did you decide to focus on .env files specifically vs. trying to tackle the broader problem? Curious about your thinking on scope vs. coverage trade-offs. Also, what's your approach to detecting what qualifies as a "secret" that needs masking? Pattern matching, or something more sophisticated?
LuckyBuddy 8mo ago
[flagged]

28 points by xinbenlv 8mo ago

theozero 8mo ago

Better than masking them in a file, get them out of the file entirely! Pull them declaratively instead - https://varlock.dev https://varlock.dev This tool also redacts from your logs if working in js.

xinbenlv 8mo ago
[dead]
- nonethewiser 8mo ago
  Bravo Founder and CEO of Namefi, but the DNS seems to resolve just fine. Do you understand the DNS space? Perhaps you could find out more using this little side project I've been working on: https://www.google.com/ https://www.google.com/.
  - theozero 8mo ago
    yeah for our DNS we use a little provider called... Cloudflare. But hey some tokenized crypto dns provider is probably much more reliable! lol
    - xinbenlv 8mo ago
      Exactly, exactly
  - xinbenlv 8mo ago
    Haha thanks my friend, well said.
verdverm 8mo ago
This appears to be the only comment you make on HN https://news.ycombinator.com/threads?id=theozero https://news.ycombinator.com/threads?id=theozero Using HN less like a marketing platform would be appreciated
NewJazz 8mo ago
What does this offer that a scriptlet that sets the envvars doesn't?

svgeek 8mo ago

OMG,I wish I had this years ago!

xinbenlv 8mo ago
Thanks, glad you liked it!

__MatrixMan__ 8mo ago

I recently made this as a component in a larger project https://gist.github.com/MatrixManAtYrService/7fc7fb05474d9717da02d0a7a8be7ca5 https://gist.github.com/MatrixManAtYrService/7fc7fb05474d971... The idea is that even if you can't see the full data for some reason (space constraints, in my case), different values will appear styled differently even if the non-hidden characters don't differ. I'm not sure how easy/hard vscode makes this, bit it might be fun to use a hash of the secret (salted by that character's index) to determine the back/foreground colors of the *'s That way even though you can't see the secret, you can tell that it has changed. Also you're in a position to notice if two hidden secrets are the same (this might clue the user into a mistake, like if they didn't actually copy what they think they copied and are instead pasting the previous thing.

dietr1ch 8mo ago

> I've always had this fear of accidentally flashing my .env file with production secrets to the whole room (or recording). Can't you just intersperse entries with multiple-screens-worth of blank lines, or add noisy variables? I'm thinking that 120 blank lines at the beginning and the end might be enough though, no need to make the file really hard to use.

xinbenlv 8mo ago
That's a good idea too, thanks for the suggestion
- dietr1ch 8mo ago
  Also, now that I think about it you could source the super secret stuff from a second file and keep the .env file publicly readable and available for quick edits while streaming

esperent 8mo ago

I recently got a phone with a high zoom level - once you factor in digital zooming it's 20x. The photo quality at that zoom level is trash, but it absolutely could be used to read text from people's laptop screens from across a big room, or even another building through a window. Of course, real cameras have always had this kind of zoom level. The difference is that now, someone could appear to be browsing on their phone from very far away, but actually be reading text on your laptop screen. It's much more likely they'll be looking for credit card details or something like that rather than .env secrets. But I guess it's better safe than sorry if you frequently work in a public, tech focused environment like a big coworking space. We're talking someone sitting with their phone 50 meters away from you being able to read text on your laptop screen. That's about the distance where a person with good vision will struggle to recognize faces.

verdverm 8mo ago
Would they need something to help with stabilization at that zoom and distance?
- canadiantim 8mo ago
  A selfie tripod
- esperent 8mo ago
  Like sitting at a table and resting their phone on it, sure.

globular-toast 8mo ago

Why would you have "production secrets" in a .env file in the first place? I feel like that's the real problem here.

deleted 8mo ago
[deleted]
xinbenlv 8mo ago
We use infiscial and other mechanism but hey, wouldn't it be nice to have one less square inch of attack surface?
- globular-toast 8mo ago
  Why not have one less square mile of attack surface by not having secrets in a .env file in the first place? What are people doing that requires something like this?
  - pjjpo 8mo ago
    I think it's common to have dev not production secrets there, and am reading the blurb about production secrets as non-local secrets. Even dev keys are a pain if they get leaked. The idea seems nice with a simple yet effective implementation. While I think I currently have a shell script syntax highlight plugin reading env files, it's definitely overkill. Now if only this could protect from random npm packages reading your env files...
    - dissent 8mo ago
      This implies there's some kind of shared resource out there on the network that your devs are developing on. Why not make all these resources part of your local dev stack, served on localhost, and use dummy credentials? You can even commit them because they're not sensitive.
      - pjjpo 8mo ago

electromech 8mo ago

or, don't put secrets in .env files...

ReluctantLaser 8mo ago

I feel I see these solutions somewhat often, but you can execute a command and use that as a value. To me, I'm not sure why people aren't calling their secret store as part of it. I use direnv mostly, but seems `.env` supports the same thing. e.g: MY_SECRET=$(pass show path/to/my/secret) Of course substitute that for Vault/SSM/whatever. There are other solutions to this problem too, but I show this to people as there's so little friction to using it. As for the solution itself, we shouldn't really be storing secrets as plain text wherever we can help it. Masking them feels like a kludge.

legitimate_key 8mo ago

Congrats on the launch! This resonates - I've dealt with the "accidentally exposed credentials during a demo" problem a lot. The .env file is one of the most common culprits, but I've found the problem extends beyond just one file type. What I've learned: The broader challenge: - .env files in code editors - Config files in various formats (YAML, JSON, TOML) - Database GUIs (showing connection strings, table data) - API tools (Postman, Insomnia showing auth tokens) - Browser tabs (logged into admin panels, showing URLs with tokens) - Terminal windows (commands with API keys) - Slack/email windows (messages with sensitive info) Most solutions are file-type specific or app-specific. But during a screen share, the sensitivity context switches constantly - one moment you're in VS Code, next you're in a browser, then Postman, then back to the terminal. How did you decide to focus on .env files specifically vs. trying to tackle the broader problem? Curious about your thinking on scope vs. coverage trade-offs. Also, what's your approach to detecting what qualifies as a "secret" that needs masking? Pattern matching, or something more sophisticated?

LuckyBuddy 8mo ago

[flagged]