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.
1,164 karma · joined October 16, 2020
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.
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.
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.
That's not how security works, but that's how a bounty works. If you can do ___, then you get ___. That's it.
If it's any consolation, I sent this project to (security professional) colleagues in the past to get their take on it. This is also not how security works, but to me is better than nothing.
Remember this is not a product. I don't care if you use it. I'm just sharing my hack for carrying secrets around without needing a special device or key.
The second one is that you can open the file in an editor and verify what it does before trying to decrypt.
Any modern browser also has protections that prevent a random HTML file from acting like a virus (stealing and uploading files).
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 the exact code that’s running.
I agree. As clearly stated in various places, this is a demo. Take the idea and fork/re-implement it for yourself.
Not looking for users TBH. :-)
re: bug in the vendor implementation of cryptography. Doesn't this apply to everything you encrypt?
Unless I hit my head really hard, there's zero chance I will forget this passphrase.
That's because it only uses NIST recommended encryption, which is baked in or available in most languages.
These are NIST-recommended algorithms, they'll be around for a while...
https://security.stackexchange.com/questions/35818/are-passw...
While it's very real in theory, I am not concerned in practice.
If I am the target of a sophisticated attacker, there are easier and more effective ways to pwn me.
A few other comments reference the same, e.g.: https://news.ycombinator.com/item?id=34085245
(I was using AES-CBC before, that's why the padding is there)
This is how the 'secret creator' page works :-)
Linked your project.
p.s. don't use password protected archives: https://security.stackexchange.com/questions/35818/are-passw...
As the old adage says 'any problem can be resolved by adding one more layer of indirection'.
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)
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?
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.
> most security professionals (myself included!) aren't equipped to outright "crack" this kind of thing in just a few minutes
When I say 'crack' in this context, I mean review the scheme and point out any obvious flaws, like you just did!
> SHA-1 -> SHA2-256
I should do this!
> reuse an IV
Indeed (there is a fine-print in the creator page that says "don't reuse across messages", but I should just regenerate proactively)
Thank you very much for the great comment!
> 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.
What amount of money would make you actually try to crack it?
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.