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

Show HN: Portable Secret – How I store my secrets and communicate privately

mprimi.github.io

Post reply on HN
Print view View original

261–270 of 385 posts

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#261

Post by maqp »

mprime1 wrote: post #238
kfrzcode wrote: post #169

> It’s portable because: decrypting these secrets does not require special software! All you need is a browser. No complex, million+ SLOC codebases to install, except the one browser. I'll stick with gpg signing my pass repo and call it a day.

To be clear: I use gpg too. But I can't expect my mom or girlfriend to learn how to use it. With PortableSecret I can communicate privately with them, without installing or learning anything new.

So explain to us the workflow of sharing data to them

Problem: Send a file securely

Solution: Encrypt file using PortableSecret, send file over unencrypted email.

Problem: Send the decryption pasword

Solution: I can't use unencrypted email to send secrets. Let me use end-to-end encrypted Signal for that

---

What problem did you solve, that didn't complicate the process of just sending the file with Signal to begin with?

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#263

Post by eurasiantiger »

AgentME wrote: post #235
distcs wrote: post #178

Earlier quoted context omitted.

For me the biggest problem with a setup like this is complete loss of access to my secrets. The crypto functions supported by browsers may change in future. A cipher algorithm used to encrypt my secrets may get deprecated and removed by the browser in future. Then I will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore. GPG or vim -x might be much better choices for secrets that n…

Standardized web APIs are very rarely removed. Backwards compatibility is a huge priority for web APIs, and cases where they're broken are rare. It's very hard for me to even think of a web API like this that browsers have ever made incompatible changes to. The parts of the web that get incompatible changes are generally stuff like nonstandard plugins (Flash being discontinued) and TLS (which isn't relevant if you're…

True, they are deprecated first.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#264

Post by maqp »

createdapril24 wrote: post #87

This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen. - Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret. - Easy to brute force. Con: Rel…

>Uses current state of art algos. Pro: Resistant to access by known methods.

AES-GCM is fine sure, but the password hashing function PBKDF2-HMAC-SHA1, i.e. what turns the user's weak password into the AES-key, is the opposite of state-of-the-art in this case.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#265

Post by maqp »

ricardobeat wrote: post #253
maqp wrote: post #251

Hate to be that guy that ruins parties but there's a couple of obvious issues here Firstly, the repeated Java Script delivery problem The library that generates random numbers is bundled in your browser. However, the code that calls that library is delivered from network every time, e.g. let iv = crypto.getRandomValues(new Uint8Array(blockSize)); This code depends on what the server yields for every connection. There…

Crypto is a browser built-in, it’s not being loaded over the network at all. The HTML file is self-contained. Even if it was loading remote scripts, they could be secured by using an integrity hash (another modern browser feature).

Yeah you can actually just audit the self-extracting code, and create detatched signature for it for every instance.

But yeah my bad, apparently the actual problems with this tools are with usage, password hashing, and non-existent secret sharing mechanisms.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#266

Post by gregw2 »

SpeedilyDamage wrote: post #216
mprime1 wrote: post #54

Earlier quoted context omitted.

It's not a service. It's a simple hack and I use it for 3-4 use cases for which no service exists. Among other things: - It works offline - My mom can use it - It works on any device (even a borrowed one or a newly formatted one) - It can save me if *all* my devices get stolen - It can save me if I'm stranded in a foreign country without any document or trusted devices, - Etc.

I get that, but why not use a service, instead of this manual process? 1pass literally can solve every single one of these problems.

Not speaking for the poster, I would rather trust a mainstream browser's crypto API than 1pass.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#267

Post by unnouinceput »

PeterisP wrote: post #255
distcs wrote: post #178

Earlier quoted context omitted.

For me the biggest problem with a setup like this is complete loss of access to my secrets. The crypto functions supported by browsers may change in future. A cipher algorithm used to encrypt my secrets may get deprecated and removed by the browser in future. Then I will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore. GPG or vim -x might be much better choices for secrets that n…

All of these crypto functions have many implementations in every popular programming language that return the exact same bits no matter which implementation you use. As long as you have the keys (which is a serious issue) and someone remembers which function was used with which parameters the risk of "will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore." is not even on the same…

I remember a few years ago on Discovery Channel, there was a documentary about people hit by lightning. One was hit by lightning 3 times, all 3 times on forehead, and survived to tell the story on record (you could see his forehead having very clear view of its underlying sanguine vessels as secondary effect).

But one story that particularly stood out was of a woman who was hit by lightning during clear weather, inside the house, through the water pipes - she was cleaning dishes at the time. So your scale might be still too small.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#268

Post by unnouinceput »

Teckla wrote: post #226
distcs wrote: post #178

Earlier quoted context omitted.

For me the biggest problem with a setup like this is complete loss of access to my secrets. The crypto functions supported by browsers may change in future. A cipher algorithm used to encrypt my secrets may get deprecated and removed by the browser in future. Then I will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore. GPG or vim -x might be much better choices for secrets that n…

The crypto functions supported by browsers may change in future. Could those crypto functions built into the browser be replaced with JavaScript implementations?

Yes, they can. There are libraries already doing that. And while slower than the native implementation in the browser they are still good enough for this tool. So fork the sources of this project and implement in JS those API crypto the browser is using and you're clear to go without relying on them.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#269

Post by maqp »

divyekapoor wrote: post #254
maqp wrote: post #251

Hate to be that guy that ruins parties but there's a couple of obvious issues here Firstly, the repeated Java Script delivery problem The library that generates random numbers is bundled in your browser. However, the code that calls that library is delivered from network every time, e.g. let iv = crypto.getRandomValues(new Uint8Array(blockSize)); This code depends on what the server yields for every connection. There…

Hate to be that guy that ruins your security researcher dreams. Your Argon2 memory hard function is useful against mass surveillance and belongs in mass market products. Let's leave it there. Despite your protests, for an average joe who just wants to stash a secret somewhere and not have it in plaintext, this is absolutely ok.

There is no reason not to use Argon2 in place of weaker alternative, especially when there's no UX overhead.

The threat model "for an average Joe who just wants to stash a secret somewhere and not have it in plaintext" should probably be written in red, font size 48.

But take a look what the author is actually saying it can be used for, i.e. to "securely store passwords". The currently available tools like KeepassXC that do just that, also use Argon2.

"Your Argon2 memory hard function is useful against mass surveillance and belongs in mass market products."

Well if this product isn't for mass-market, it's for niche use, and here I thought niche products are usually for the special security cases for people who need extra security, but you're implying average Joes should NOT use mass market grade security but something niche and less secure.

Re: Show HN: Portable Secret – How I store my secrets and communicate privately

#270

Post by AgentME »

eurasiantiger wrote: post #263
AgentME wrote: post #235

Earlier quoted context omitted.

Standardized web APIs are very rarely removed. Backwards compatibility is a huge priority for web APIs, and cases where they're broken are rare. It's very hard for me to even think of a web API like this that browsers have ever made incompatible changes to. The parts of the web that get incompatible changes are generally stuff like nonstandard plugins (Flash being discontinued) and TLS (which isn't relevant if you're…

True, they are deprecated first. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That page supports my point! Most of the things in that list still work in browsers, and the few things that don't still work look like they're all things that never got standardized to begin with.
Post reply on HN