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

Show HN: Laptop is the last place your secrets are still in plaintext

github.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#71

Post by bukershok »

hnlmorg wrote: post #69
bukershok wrote: post #66

Earlier quoted context omitted.

hnlmorg, i must disagree with you on this one, that most people do not have passwords in plain text. If you a developer or just using API in your day to day you will have secretes in plaintext on your projects.

This isn’t aimed at people who aren’t developers nor use APIs in their day-to-day. So it seems odd to include mum-and-pop macOS users in your context.

My bad I misread your quote blocks we're actually saying the exact same thing. Thanks for defending the use case and highlighting the ~/.aws point.

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#72

Post by nf-x »

ekianjo wrote: post #43

on Linux use systemd-credentials. It already does that

there are so many great tools in the baseline core infrastructure. and there's so much NIH syndrome still.

appreciation and OS aside, systemd-creds relays long-lived creds into long-lived processes, and author's AI slop attempts at short-lived/on-demand injections. Apparently, author's AI slop gets a lot of iterations, but has not much of external scrutiny yet.

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#73

Post by necovek »

Faaak wrote: post #31
necovek wrote: post #9

While this might be a useful tool for Mac users, it's all hackers here, so: * Most people do not have passwords in plain text — an SSH key protected with a passphrase is not "plain text", for instance * Most people have encrypted home or full disk encryption * How can we trust your crypto implementation? * If we are talking about in-memory plain-text during use, how does this tool protect against it? * Containerisati…

> Most people have encrypted home or full disk encryption I don't see the point. Once your home is unlocked, every process can see the file contents

I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved.

Eg. imagine there's the source code for a service you deploy to AWS — rogue sw can modify it letting you unknowingly update it the next time (or why do you have those AWS keys anyway?).

But not if they are part of non-classic Snap on Ubuntu or properly containerised Flatpak (on Linux, at least), or in a VM or LXC/Docker/Podman container.

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#76

Post by bukershok »

Animats wrote: post #3

The install procedure, for something that's supposed to be a security product: curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit sudo mv jit /usr/local/bin/ What could possibly go wrong?

that line just pipes a tar archive into tar to extract the binary, not an executable script to a shell. That said, brew install jitpass/tap/jitpass is the recommended way to install.

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#78

Post by jan_tilde_zone »

Great Implementation. I was always looking for a way to further lock down credentials on Mac machines in our org. This could be a great additional layer of defense against supply chain attacks.

Especially the 8 hours valid aws SSO access token felt super risky to have available in plain text. Would those those temporary credentials work as well?

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#79

Post by nf-x »

jan_tilde_zone wrote: post #78

Great Implementation. I was always looking for a way to further lock down credentials on Mac machines in our org. This could be a great additional layer of defense against supply chain attacks. Especially the 8 hours valid aws SSO access token felt super risky to have available in plain text. Would those those temporary credentials work as well?

to begin with, why not setting validity for 1hr? you don't need to onboard an untrusted tool then.

Re: Show HN: Laptop is the last place your secrets are still in plaintext

#80

Post by necovek »

hnlmorg wrote: post #39
necovek wrote: post #9

While this might be a useful tool for Mac users, it's all hackers here, so: * Most people do not have passwords in plain text — an SSH key protected with a passphrase is not "plain text", for instance * Most people have encrypted home or full disk encryption * How can we trust your crypto implementation? * If we are talking about in-memory plain-text during use, how does this tool protect against it? * Containerisati…

I'm not the author but i can probably answer some of these: > * Most people do not have passwords in plain text — an SSH key protected with a passphrase is not "plain text", for instance I think you'd be surprised how many SWE do actually have plain text secrets. For example, if you do everything correctly with AWS auth, you still have a plain text token in ~/.aws -- it's short lived (typically 8hrs IIRC), but it's s…

Your local development machine will have the source code or images or IaaC configuration that you push to GH/AWS — a rogue agent can just modify that and wait for you to authorize the next push.

I'd also consider short-lived tokens "in-memory during use", even if 8h is not very short.

If you have AWS keys but do not have anything you use them for, then yes, a tool like this will help.

However, the tool seems to implement per-provider handling, meaning large surface area and new risks replacing old ones. Even standard, trusted crypto libraries are frequently misused in insecure ways.

I can certainly explore the code, but as it is a "Show HN", I'd like the author to show it ;)

My point is to understand clearly where does author believe this tool has merit.

Post reply on HN