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

31–40 of 93 posts

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

#31

Post by Faaak »

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

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

#32

Post by QuantumNomad_ »

tgv wrote: post #18
kokx wrote: post #14

Earlier quoted context omitted.

It's not piped to a shell, but to the tar program with specific parameters to directly unpack the tar. You're still installing the program directly from github of course, instead of a source where hopefully a third party has also looked at it (like a package repository). But this is a lot better than the curl | sh pattern.

You're not downloading from github, but from dl.jitpass.com. And an executable can do exactly the same as a shell script. The point is that whatever you're executing isn't verified, whether it's a shell script or a binary.

> The point is that whatever you're executing isn't verified, whether it's a shell script or a binary.

The GP said:

> This should be an ordinary app bundle to drop into /Applications

There is no difference between downloading an app bundle that you drop into /Applications, and curling a binary that you put in /usr/local/bin/

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

#33

Post by _august »

I've moved my secrets to 1Password Environments (https://www.1password.dev/environments), which works really well for everyday use.

It works with 1password cli (https://www.1password.dev/cli) to access for agents/scripts, and I get a nice UI to manage them in the 1password app.

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

#34

Post by ZiiS »

tgv wrote: post #18
kokx wrote: post #14

Earlier quoted context omitted.

It's not piped to a shell, but to the tar program with specific parameters to directly unpack the tar. You're still installing the program directly from github of course, instead of a source where hopefully a third party has also looked at it (like a package repository). But this is a lot better than the curl | sh pattern.

You're not downloading from github, but from dl.jitpass.com. And an executable can do exactly the same as a shell script. The point is that whatever you're executing isn't verified, whether it's a shell script or a binary.

The difference is you have the executable for examination (at least a quick virus scan) before you run it. Certanly not perfect, but what is?

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

#36

Post by nf-x »

How funny it may sound, but I was recently researching around for these kinds of tools for the same exact purposes.

Where I got stuck was at the Secure Enclave storing biometric-crypted payloads in the keychain, but couldn’t get it to work without Apple Developer subscription for code signing, otherwise these features wouldn’t work. And nobody with an Apple Developer subscription wants to sign someone else’s code, obviously. I really wonder why Apple itself, or any other reputable company, didn’t publish an utility like this already - it’s also a trust issue, when you run code like this.

The issue is that /usr/sbin/security invocations can be obscured to read from keychain, but require password typing every time, which is annoying. And lazy people can just hit “trust” by mistake. And then it’s just another clear text, but more annoying to reach.

Even though, it may be possible to show a touchID prompt in two other scenarios: - encrypting payload with a key stored in the enclave - then it becomes closer to SOPS approach. Age plugin for sops also supports using private keys on yubikey, by the way. But SOPS UX feels clunky. - just calling the APIs to show touchID as part of the application logic, like all modern password managers do. But then you really have to trust the password manager or the tool that does it, because touchID doesn’t equal security in this case.

Some password managers support CLI, SDK, and Terraform providers for working with their secrets, but that requires an IPC enabled, potentially increasing the risk for the other secrets stored in the same password manager.

Oh well, tough choices everywhere.

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

#38

Post by vintagedave »

zahrevsky wrote: post #6
vintagedave wrote: post #2

Interesting idea! How do you achieve it? Some kind of file system driver that recognises the calling process?

If only there was a Markdown file in the repo, that explains it. It could have a URL, say, https://github.com/jitpass/jit/blob/main/docs%2Fgetting-star...

Please avoid the snark.

I read the readme in full, I think that's an appropriate level of effort. Your link also still doesn't answer it, though it hints: 'A migrated .env is a live mount (a named pipe), not a plain file'. So is that a file system driver, or...?

Even https://github.com/jitpass/jit/blob/main/docs/getting-starte... says it's a local encrypted store - and that's repeated many times across the docs Claude-style - but it doesn't explain the mechanism whereby reading a file gets the results from that store.

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

#39

Post by hnlmorg »

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 still there

> * Most people have encrypted home or full disk encryption

Yes. But that addresses a completely different problem. One where the whole machine is lost and an attacker then has physical access to your machine. Not when the machine is already in use and you have a rogue agent or other process.

> * How can we trust your crypto implementation?

This is written in Go and Go's standard library already has crypto functions. So there wouldn't be any need for the authors to roll their own implementation. But since it's open source, you can always check the code yourself.

> * If we are talking about in-memory plain-text during use, how does this tool protect against it?

This tool doesn't advertise that feature. Which I'm guessing you already knew. macOS, like most popular operating systems, does already have kernel-level code that makes it harder for processes to read the memory of other processes that do not belong to it. It's not entirely impenetrable, but this tool I think goes far enough for most SWE's risk appetite. If the risk that you need to guard against is greater than that, then you'd be looking at VM-level isolation rather than this kind of tool.

> * Containerisation is a big topic when running untrusted software for exactly (but not just) this reason

Indeed. And while personally, I'd still recommend containerisation, that doesn't mean this kind of tool doesn't also have merit. For example containerisation can get complicated if you have several processes that might need to work against the same project.

> * While passwords/tokens might carry a big risk depending on what you do, I find that I worry more about my local data compared to my remote data — and virtualisation or containerisation helps with that.

This surprises me because even if you're not using cloud computing, your local machine is still typically just the development environment and it's your "remote" (whether that's in a DC somewhere or hosted on-prem) is where the actual data, compute and infrastructure exist.

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

#40

Post by nf-x »

_august wrote: post #33

I've moved my secrets to 1Password Environments ( https://www.1password.dev/environments ), which works really well for everyday use. It works with 1password cli ( https://www.1password.dev/cli ) to access for agents/scripts, and I get a nice UI to manage them in the 1password app.

But the IPC is process-wide, not vault-dependent. And requires touch approval on every access, without “trust this process for X minutes” possibility.

Other 1pass is a great UX. It was even greater before Electron refactor and non-subscription model.

Post reply on HN