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

111–120 of 385 posts

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

#111

Post by woodruffw »

mprime1 wrote: post #6
ortusdux wrote: 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.

The first few times I shared this with (security professional) colleagues and friends, they'd dismiss it right away "this can't possibly work", but it was because they _assumed_ it didn't work (too simple). Attaching a challenge made a big difference, they'd spend 5 minutes trying to crack it and, in the process, realize it is actually sound (despite the simplicity).

I think this is very cool, and from a cursory look you've made most of the right design choices (to the extent that the Web Crypto API allows).

That being said, I think most security professionals (myself included!) aren't equipped to outright "crack" this kind of thing in just a few minutes, and most should know better than to think that their inability to do so implies soundness.

With that in mind, here are some things I noticed (none of which represent an immediate break!)

* You're using SHA-1 in your KDF. That's probably fine since PBKDF2 doesn't rely on the properties of SHA-1 that have been broken, but the Web Crypto API gives you better alternatives. You could switch it out for SHA2-256 here without any breakage to the rest of the scheme.

* I'm not a JS expert, but I _think_ your encryption page might allow a confused user to reuse an IV[2]. Normally this wouldn't happen because the user would refresh or reload and trigger the `init` on page load, but it would probably be better to generate the IV on demand rather than having it wait in an HTML attribute.

Again, very cool work! The fact that people can make these kinds of self-containing encrypted applications with Web APIs is a serious testament to how far the standards have progressed.

[1]: https://github.com/mprimi/portable-secret/blob/3b22d2b42baf8...

[2]: https://github.com/mprimi/portable-secret/blob/4de5e958fe6f8...

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

#112

Post by TedDoesntTalk »

mprime1 wrote: post #105
d4a wrote: post #67

I made something similar a few years back when I was learning web dev. It's not nearly as polished, but I'd love to pick apart your code and see what design decisions we did similarly/differently https://9p4.github.io/hackna/ The big difference is that your project is self-contained in an HTML file, which I think is a much better design

Cool! Added a link to your project

I did the same thing before WebCrypto by including an AES JavaScript library in the page. Nice work.

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

#113

Post by Kon-Peki »

mprime1 wrote: post #75
clarge1120 wrote: post #52

Cyphers, the algorithms used to encrypt the secret file, become obsolete over time. We still need to solve for obsolescence. You can encrypt a file today using a cypher that will eventually be removed from all browsers, desktops, and phones.

2 sides of obsolescence: - Too old, no software can decrypt it: not worried about this. These are NIST-standard algorithms, there built-in in most programming languages, they'll be around for a while - Too old, trivial to crack: this is a bit more concerning to me. It's possible that some entities around the world can already crack this encryption in minutes/hours days Regarding the second, I'm already working on an…

Well, your cipher text could decrypt to a non-published URL that has some cipher text which decrypts to another non-published URL (as many layers of indirection that you need), with the final non-published URL containing the actual cipher text you wanted to decrypt.

You can check server logs to see if those URLs are ever hit.

And if you ever need to, you can abandon the original link after changing what those non-published URLs point to (something "fun", like a rickroll perhaps).

In fact, how about using the Wayback Machine to store a bunch of versions of the static page, each containing different versions of the cipher text. Only you know which date range contains the proper cipher text!

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

#114

Post by catapart »

This seems like a really good proof of concept to let browser vendors know they could create a super useful utility in their browsers.

I mean, it's very cool all on it's own, and great job in building it! I'm just hopeful that someone is taking notes.

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

#115

Post by TedDoesntTalk »

aporetics wrote: post #78
c22 wrote: post #50

Earlier quoted context omitted.

Like sibling comment elucidates, code-golfing is just using tricks to get the size of a program down without impacting its functionality. This could be as simple as using single-character variable names or something more complicated like including a decompressor that expands some packed code before execution. If you got the decryption code plus the payload small enough you could theoretically put the whole thing into…

This used to be called munging

It’s called minification in the JavaScript ecosystem.

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

#116

Post by mprime1 »

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…

Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular:

> Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret

This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates me and sends a fake 'PortableSecret' to Bob that siphons out the actual password.

Clearly this is a valid vector of attack, and one I made no attempts at defending from.

The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous.

I have to keep reminding myself this is a real vector, but the fear is irrational.

As they say at DEFCON to people too concerned using their devices: "Nobody is wasting their 0day on you".

I don't think I'm a target valuable enough to attract this kind of attacker.

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

#117

Post by woodruffw »

createdapril24 wrote: post #107
admax88qqq wrote: post #103

Earlier quoted context omitted.

> Con: Eventually the secrets will become exposed due to advances in crypt-analysis You can claim this con for literally any crypto. And I'm not actually sure it's a reasonable assumption. Block ciphers seem to be pretty unbreakable so far. Even good ol Triple-DES is secure in practice barring some caveats (don't encrypt more than a certain amount of data) I'd wager if I gave you a real world message encrypted with A…

That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility . It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with p…

Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks.

Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.

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

#118

Post by redbell »

> Crack me if you can

This reminds me of LifeLock CEO's Todd Davis public challenge [1] when he revealed his Social Security number prominently on his site and billboards with overconfidence that his identity cannot be stolen but, unfortunately, he's been a victim of identity theft at least 13 times.

1. https://www.wired.com/2010/05/lifelock-identity-theft/

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

#120

Post by europeanguy »

skrebbel wrote: post #102
europeanguy wrote: post #86

Earlier quoted context omitted.

What happened to the "don't roll your own crypto" that HN loves?

this doesn't, it uses the browser's builtin Web Cryptography API. if using a crypto algorithm also counts as "rolling your own crypto" then what's left? just don't encrypt anything, ever, because HN says we shouldn't roll our own?

Yes, using a crypto algorithm also counts as rolling your own crypto. You're putting together crypto libs that others wrote. Most crypto vulnerabilities come from glueing together solid crypto implementations. The glueing has to be solid too. Just "using" a crypto algorithm sounds like a recipe for a vulnerability.

I'm not a crypto expert, I'm just telling you what I've been reading on HN for the past few years.

Post reply on HN