131–140 of 385 posts
* 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.
Any way to make this work with passkeys?
WebAuthn also only works in secure contexts (HTTPS)—you couldn't make it work in a plain .html file.
Earlier quoted context omitted.
What happened to the "don't roll your own crypto" that HN loves?
I can't be the only one who thinks this wallet will be emptied before 2023. Security by obscurity is real, there's nothing secret about defining the problem space in which your attackers can search.
This is what the bounty is for. I just hope whoever cracks it lets me know how they did it and how hard it was.
This is what a bounty is, no?
Earlier quoted context omitted.
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…
Agility does nothing to stop the "ciphertext from the past is broken due to crypto improvements". It's just a means to shorten response time to crypto breaks for _new_ traffic. This project is plenty agile, upgrading the primitive is very easy as it's not a communication protocol but a data at rest protocol. > this one doesn't have parameter negotiation and key management You're thinking in terms of live communicatio…
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 from a break or weakness to a fix, forcing any adversary who has not already recorded communication traffic to do so in a hurry.
In this setting as a "data at rest" protocol, the work to persist the ciphertext has been done for the attacker. If there's a weakness or break it's up the defender to clean up all copies of the old secret ciphertext that's out there and publish new ones. In cases where the secret has been cached (e.g. Wayback Machine) that may not be possible.
I hope you agree with this nuance that there's something the defender needs to consider. I agree with you that not all defenders will find this consideration will be decisive in their decision to use this method or not.
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…
One possible attack is someone changing either the encrypt or decrypt source code, either via Github (if they get access to the OP account) to log keystrokes. Or if someone has hosted it themselves then hack that hosting provider. Or they could do something like this: https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha... Phishing is another potential one. Browser extensions, or supply chain attack on packag…
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)
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 the exact code that’s running. If you’re an especially valuable target, you can’t even be sure that the files that you think you’re serving haven’t been tampered with.
Earlier quoted context omitted.
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.