Live data from Hacker News

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

mprimi.github.io

221–230 of 385 posts

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

#221

"long sequence of words that are trivial for me to remember" I also thought so until I suddenly forgot a master password I have been using for several years. Luckily, I was able to recollect it after several days. Then, I forgot it again. Age, decease and head trauma can happen.

By "long sequence of words that are trivial for me to remember" I meant concatenation of secret questions, like in the bounty example: https://mprimi.github.io/portable-secret/examples/bounty.htm... Unless I hit my head really hard, there's zero chance I will forget this passphrase.

Keys should be random. The hints make it too easy. Lets say there exist 100 male names and 100 female names, thats just 100*100 combinations for names part. You could make the key generation intentionally slow though to limit the crack speed.

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

#222

I created something similar to this [1] a few years ago. Before the proliferation of web crypto apis, I just used a WASM’d libsodium. It adds some page weight but whatever… My use-case was for traveling, it seems like a good idea to have a backup photo of my passport and credit card in case I loose everything. Sure I could put it on Dropbox, but do I really want to log in to my entire Dropbox on someone else’s machin…

Cool!

Main difference I see: you have thousands of lines of JS in your vault. Mine is a lot simpler because it uses the browser Cryptography APIs.

Linked your project from the README.

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

#223

Earlier quoted context omitted.

I really do hear what you're saying and think you're making a great point. The part that I think applies is that this is a "data at rest protocol". Communication protocols are assumed (but maybe shouldn't be - a la PRISM disclosures?) ephemeral. As an attacker, I need to have been in the middle for that specific instance of the communication, and save it for decades, to attack it. Crypto agility shortens the window f…

I just think it's a misleading analysis to say "this system is vulnerable to XYZ" without including the fact that ALL systems in this class are equally vulnerable. Crypto agility is not a thing that can be applied to encryption at rest. It's similar to criticizing an alcoholic drink by saying "this drink will cause liver damage" as opposed to saying "this drink, like all alcoholic drinks, will cause liver damage" Wit…

At this point I can not edit the top comment. I would have edited with something like: "this property is not an implementation bug but a design outcome shared with any deployment of cryptography that persists ciphertext data in public."

Of course in future I will endeavour for more clarity and hope others read into this thread.

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

#224
post #180
post #126

Cool project! This stuff is all possible thanks to the SubtleCrypto API ( https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... ), which became widespread in browsers in the last ~5 years. It's so great we don't have to use weird libraries (some with pretty gnarly side channel leakage) to do cryptography anymore. It wouldn't be that crazy for the browser to do the encryption part for me, right? Like, what i…

What level of confidence is there that all this API will work exactly as it works now after 30 years? I am concerned that they might at the very least deprecate and remove the ciphers used to encrypt my data in portable secret. Worse what if they remove support for the API? Then I am going to have HTML files with data I cannot decrypt anymore, right?

You can always implement the decryption yourself, it’s not particularly difficult. But realistically, software doing so will continue to exist for a long time, and there will be extensive transition periods to migrate your secrets to a newer algorithm.

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

#225
post #98

Earlier quoted context omitted.

All words appear in some wordlist. This is the kind of password I use to protect my actual secrets. So if someone is able to crack it, I'd like to know. The bounty is for a 'realistic' use case.

If you want to avoid wordlist vulnerabilities, try this: Choose a lyric from a favorite song. Concatenate the first letter of each word in the lyric. Example: “Rock the Casbah Sharif don't like it” Becomes: rtcsdli Add capitalization or numbers/special characters according to your own pref. For example, maybe your decide to alternate lower and upper case and always end with a bang: rTcSdLi! Although you have to use t…

If your favorite song is by Pearl Jam you get an extra layer of security:

https://www.youtube.com/watch?v=xLd22ha_-VU

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

#226
post #178
post #131

If anyone is actually going to use this for their top secrets, I can find two things to be aware of. * When you decrypt then close the tab and open the tab again via the recently closed tab, the password is still there. * Browser extensions could read the contents of the webpage. So if anyone is going to use this, they should do it in a "clean" incognito browser without any extensions.

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?

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

#227
post #168

Earlier quoted context omitted.

The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force": "Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption" The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and ag…

Right, agree with all of that. I would have characterized as "user can shoot themselves on the foot (i.e. by choosing weak password)", rather than "easy to bruteforce"

It's a perspective difference.

Each individual user perspective: "It is possible I can shoot myself in the foot, and also possible I will not. It is not correct to say I will shoot myself in the foot.".

Outside observer perspective: "Empirically, many users shoot themselves in the foot using this system. It is correct to say this system does not make feet safe".

It might be phrased better in terms of safety than security? The safety of the system is left up to the users, and is - to the best of our knowledge - not safe to use _as is_ by most people.

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

#228
Great project!

Thinking of using this as the final backup, something to store 2FA backup codes/recovery codes etc, basically a way to end circular-dependency on my password manager, i suppose one would host this using free public hosting, maybe cloudflare pages on a hidden website, basically something reliable and trivial to access.

however relying on localstorage, which can be accessed by extensions worries me, but i couldn't replicate the password showing up in browser history thing(using brave).

seems the best option for my use case so far, maybe a self extracting 7zip archive with file name protection is better?

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

#229
post #204

> I keep a copy of my passport encrypted on the internet. What use is the picture of your passport? It would be easy to fake.

It saves a bit of time for your embassy if you need a new passport urgently in another country. > Safeguard Your Documents! Make two copies of all your travel documents in case of emergency. Leave one copy with a trusted friend or relative at home and carry the other separately from your original documents. To help prevent theft, do not carry your passport in your back pocket, and keep it separate from your money. ht…

Ditto.

And in addition: peace of mind.

Having a copy may not do much from legal perspective, but I'm just less worried if I know it's there.

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

#230
post #139

Using browser crypto to create a document is the right thing to do, but you might want a JavaScript decryption library to improve portability and lifespan. I would check that it’s capable of decrypting the payload when you’re making a document. (Possibly https://github.com/travist/jsencrypt ) The obvious weakness is your hosted document creator: it’s essentially impossible to defend an HTML document against a malicio…

> might want a JavaScript decryption library to improve portability and lifespan How does a library improve portability and lifespan? I'm only using NIST-recommended encryption algorithms provided by W3C Crypto APIs. > The obvious weakness is your hosted document creator: it’s essentially impossible to defend an HTML document against a malicious domain. We can look at your GitHub repo, but there’s no guarantee that’s…

Sorry, I should have started off by saying that this is a great idea! I’m a big fan of encryption and those old, offline things we used to call “files”.

> How does a library improve portability and lifespan? I'm only using NIST-recommended encryption algorithms provided by W3C Crypto APIs.

I’ve been writing software long enough to have been around the block a few times, and the web ecosystem hasn’t been pretty. Things get added, things get taken away, someone discovers some edge case in an API that’s not used very often and instead of being patched it’s just dropped (https://developer.chrome.com/blog/deprecating-web-sql/ or https://chromestatus.com/features#removed). Web apps shouldn’t but often do require significant maintenance.

In that context, it’s likely that something about the API that you’re using will stop working in a few years. Someone who wants to make a new document could bring things up to date and publish a new version. But existing documents? The ones used by friends and family who aren’t as technical, they’ll stop working.

The other side of the web is that the ubiquitous parts, basic HTML and JavaScript, will be supported pretty much forever. People want to see that their browser will render popular old pages, at least ones that don’t use super fancy things. Using a random encryption library to encrypt things could leave your cypher text vulnerable, but using a random decryption library (that’s verified to be able to decrypt) doesn’t have the same risks. It will, however, work pretty much forever (as long as it doesn’t rely on any browser APIs) which is ideally how long our files should last.

Congrats on building a cool thing!

Post reply on HN