Live data from Hacker News

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

mprimi.github.io

361–370 of 385 posts

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

#361

I noticed you are using pbkdf2 to convert password to key. It's recommended to use ARGON2 nowadays. From some googling, pbkdf2 increases CPU usage to make brute force harder, scrypt increases memory usage to make brute force harder. ARGON2 increases CPU and RAM usage to make brute force harder. There are other advantages as well, and it is considered the best key derivation function right now.

Fair point, I'd switch to Argon2, but it is not part of the W3C Cryptography APIs so I'd need to bring in a library or hand-roll and implementation.

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

#362
post #230

Earlier quoted context omitted.

> 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. Thing…

Algorithms are standards recommended by institutes like NIST, so probably not going to change anytime soon.

To your point, the W3C Crypto library APIs might change, and break my secrets. Unlikely but possible.

I don't know that bringing in a library makes this better: it could use features/constructs of the language that get deprecated and break.

There's other factors to consider (convenience, amount of review a given implementation has gotten, etc).

Overall, agree to disagree. Using a library has slightly different tradeoffs and I can see why you are recommending it. But I stick by my choice to depend on browser APIs.

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

#363
post #334

Earlier quoted context omitted.

Argon2-HMAC-SHA512 more like it? Or something else?

Argon2 is built on top of BLAKE2 but the hash function isn't what's making it so effective, it's memory hardness, i.e. it fills the RAM when deriving a key from password, which makes massively parallel attacks impractical because GPUs / ASICs don't have petabytes of RAM just lying around.

Cool thank you - thought so, but always good to check :)

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

#364
post #2

"Do you think this cannot possibly be secure? Great, prove it. This secret contains the recovery key for a Bitcoin wallet. Crack it and take my money!" Love it.

Offering a bounty like this has value, but probably only for finding shallow bugs. Thoroughly evaluating security/cryptography takes deep expertise and a lot of time. You're not going to elicit that without more money, impact/fame, or technical excellence. - Money: The original bounty was $400. An expert can probably earn $400 an hour just to investigate something, without needing to completely break it. - Impact/fam…

FWIW, I (author) agree wholeheartedly with everything you say.

I'm just sharing a little hack I came up with. I hope some people add it to their toolchain (not my specific implementation, the idea in general).

And offering a bounty seemed like a fun things to do, which may also catch some shallow bugs, reward the hunter, and shame me publicly :-)

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

#365

Earlier quoted context omitted.

I agree phishing is the most scary vulnerability for this. In practice, when exchanging emails with my mom, I'm not concerned about it. A sophisticated attacker has many easier ways to get into my stuff than creating a fake PortableSecret. (more detail in a different comment: https://news.ycombinator.com/item?id=34084887 )

If you get 100,000 people using your site to exchange secrets, the bounty got a lot bigger. For phishing you and your mum might be immune, but one of the 100,000 might get phished. For taking over the account (which is now more juicy, could be some bitcoins there) then everyone would be vulnerable who doesn't check the source code each time they load the page.

In order to have 100'000 potential victims, you need to have an attacker that knows 100'000 users using this and details of how what they do with it in order to convincingly phish them.

That would be a very sophisticated attacker. So back to my original point.

Beside. The README states pretty clearly this is 'demo' tech. Learn the trick and use it on your own. Depending on my GitHub tool for your critical secrets is not a good idea.

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

#366

Earlier quoted context omitted.

Author here. I do use a password manager. PortableSecret is a complement, not a replacement. e.g. where do you store the recovery key for your password manager? I also use this to store tax documents and other mildly secret documents which definitely don't belong in a password manager that copies to who-knows-where-and-in-how-many-copies.

So out of curiosity, what password manager do you use? And as apparently you don’t trust your password manager, why do you use one? And how do you determine what is “useless” enough to be entrusted to that password manager you do not really trust?

I use multiple ones, they're kinda compartmentalized. One for web logins, one for critical operational secrets, one for 'cold storage'. Plus variants of PortableSecret for various other odds and end use cases like emergency recovery USB drives.

I trust everything I use to some degree. Otherwise I wouldn't use it in the first place. But the world is not black and white.

Just because I trust something enough to store secret X in it, doesn't mean I should automatically use it to store secret Y.

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

#367
post #338

Earlier quoted context omitted.

What does “time limited” mean here?

Time-limited i.e., you rotate master key after a fixed time, say 1 month/1 year etc., depending on the use case. During that period the content can be recovered by using the masterkey to unwrap the data key and decipher the content. Beyond that period, if you don't remember the master key, you cannot decrypt the content. The time-period is only a shortcut. So, for personal use, as the OP intended, resetting the maste…

Time is a finicky concept with computers.

Could your time-based scheme be defeated by changing the system clock on the attacker computer?

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

#368
post #272

Earlier quoted context omitted.

Yes, that's one way to put it. p.s. don't use password protected archives: https://security.stackexchange.com/questions/35818/are-passw...

How about you explain the problem with password protected archives and explain how you solved it, instead of linking to something and seeing if it sticks.

I asked myself in the past 'how secure are password-protected zip files?', and the answers I found online all seem to agree on 'not very secure'.

Rather than trying to explain why, I provided a reasonably reputable source with a good summary. Read it if you are curious. Or don't. No need to be bite.

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

#369

Earlier quoted context omitted.

I'm not that confident in my tool. That said, I ask myself every day if having my public identity associated to my project, website, etc. Was a good idea. It certainly helped with jobs in the past, but it's scary to hear stories of devs impersonated by others.

Your tool would be safer if you used CBC (with some MAC) rather than GCM as the cipher mode, so that key & IV reuse would not be as dangerous. That said, since you generate a different salt and IV every time, the likelihood of key & IV reuse is very low, and having to implement an AEAD cipher mode by generic construction would be somewhat annoying. So I think the choice of GCM is fine enough.

I started with CBC (without MAC) and upgraded with GCM since it was a more convenient way to provide integrity without adding the MAC step manually.

I should really make sure IV/Salt are regenerated automatically after use. (there is a small print warning in the creator about reuse)

Post reply on HN