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

61–70 of 93 posts

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

#61

Post by fragmede »

ZiiS wrote: post #34
tgv wrote: post #18

Earlier quoted context omitted.

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?

Is there McAfee for Mac? There's no real difference. You're trusting someone not to root your shit. Whether it's via curl, dmg, or apt, we have no idea who anybody really is, so it's all on an assumption that people aren't evil. Unfortunately it turns out that there are evil people out there, but doing it via curl | bash or downloading a dmg or though some app store, there's still evil that's gonna get you if you end up trusting in the wrong people.

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

#62

Post by chanux »

nf-x wrote: post #36

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, ob…

> potentially increasing the risk for the other secrets stored in the same password manager.

As pointed to me by a friend, this is one reason not to give in to the convenience of the secrets manager you already use.

My use case for fnox with keepassdb back-end was partially validated but as I mentioned elsewhere in the thread, having to set master password in an env var is a bit of snag for the workflow.

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

#64

Post by nf-x »

chanux wrote: post #62
nf-x wrote: post #36

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, ob…

> potentially increasing the risk for the other secrets stored in the same password manager. As pointed to me by a friend, this is one reason not to give in to the convenience of the secrets manager you already use. My use case for fnox with keepassdb back-end was partially validated but as I mentioned elsewhere in the thread, having to set master password in an env var is a bit of snag for the workflow.

keepass is great, because it doesn't require any service to operate - it's just a file. technically, you are responsible for backing it up, but more centralized options possible. I used it for 4 years pre-touchID era in a corporate setting and it worked great. For a single device. UX was very "open source", but hey - it's a free software with other focus in mind.

i know other people partitioning their secrets into multiple keepassx vault files, so the argument about using the same password manager can be interpreted differently.

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

#65

Post by ZiiS »

hnlmorg wrote: post #42
ZiiS wrote: post #34

Earlier quoted context omitted.

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?

You can still do that with their install instructions ;)

That is what I am saying, you are trusting them, but less then `curl | sh`

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

#66

Post by bukershok »

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…

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.

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

#67

Post by ZiiS »

fragmede wrote: post #61
ZiiS wrote: post #34

Earlier quoted context omitted.

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?

Is there McAfee for Mac? There's no real difference. You're trusting someone not to root your shit. Whether it's via curl, dmg, or apt, we have no idea who anybody really is, so it's all on an assumption that people aren't evil. Unfortunately it turns out that there are evil people out there, but doing it via curl | bash or downloading a dmg or though some app store, there's still evil that's gonna get you if you end…

Well trusting McAfee¹ is one of the choices.

¹ https://en.wikipedia.org/wiki/John_McAfee#Legal_issues

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

#68

Post by bukershok »

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

[dead]

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

#69

Post by hnlmorg »

bukershok wrote: post #66
hnlmorg wrote: post #39

Earlier quoted context omitted.

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…

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.

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

#70

Post by [deleted] »

porridgeraisin wrote: post #54
ekianjo wrote: post #43

on Linux use systemd-credentials. It already does that

Yes, you can even have it tpm-backed. echo -n "sk-proj-12345..." | systemd-creds encrypt --with-key=tpm2 --name=openai_key - openai.cred And then at runtime export OPENAI_API_KEY=$(sudo systemd-creds decrypt openai.cred)

[deleted]
Post reply on HN