Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mprime1
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
10 ms
·
91.
▲
by
mprime1
4y ago
The HTML is self contained and works offline.
92.
▲
by
mprime1
4y ago
Data URLs have a limit, but from what I read online it is browser and platform specific. But before you hit that limit, your browser may kill the tab because it looks like it's using too many resources. Again hardware/browser/
93.
▲
by
mprime1
4y ago
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.
94.
▲
by
mprime1
4y ago
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.
95.
▲
by
mprime1
4y ago
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
96.
▲
by
mprime1
4y ago
"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!". I'm sorry but that's not how security works. That's not how s
97.
▲
by
mprime1
4y ago
A 'portable secret' is a self-contained HTML file. You can open and decrypt it without an internet connection. This is I think one misunderstanding. The second one is that you can open the file in an editor and verify what it does
98.
▲
by
mprime1
4y ago
> 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 obvio
99.
▲
by
mprime1
4y ago
Thank you for the pointer https://clipperz.com
100.
▲
by
mprime1
4y ago
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"
101.
▲
by
mprime1
4y ago
Thank you for the insightful comments. Not looking for users TBH. :-) re: bug in the vendor implementation of cryptography. Doesn't this apply to everything you encrypt?
102.
▲
by
mprime1
4y ago
And there are ciphers who have lived much longer than 30 years... https://en.wikipedia.org/wiki/Caesar_cipher
103.
▲
by
mprime1
4y ago
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... Unle
104.
▲
by
mprime1
4y ago
Looking at the HTML/JS code does tell you how to implement decryption in a different language. That's because it only uses NIST recommended encryption, which is baked in or available in most languages.
105.
▲
by
mprime1
4y ago
> 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
106.
▲
by
mprime1
4y ago
But not secure... https://security.stackexchange.com/questions/35818/are-passw...
107.
▲
by
mprime1
4y ago
Phishing is indeed the most glaring vulnerability of this. 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
108.
▲
by
mprime1
4y ago
Thank you!
109.
▲
by
mprime1
4y ago
You are saying padding might be superfluous because of AES-GCM, correct? (I was using AES-CBC before, that's why the padding is there)
110.
▲
by
mprime1
4y ago
> If you got the decryption code plus the payload small enough you could theoretically put the whole thing into a data URL (a URL that doesn't link to a remote resource, but contains all the data needed to display a web page) This
111.
▲
by
mprime1
4y ago
Neat! I knew I could not possibly be the only one that had this idea. Linked your project.
112.
▲
by
mprime1
4y ago
Yes, that's one way to put it. p.s. don't use password protected archives: https://security.stackexchange.com/questions/35818/are-passw...
113.
▲
by
mprime1
4y ago
Genius. As the old adage says 'any problem can be resolved by adding one more layer of indirection'.
114.
▲
by
mprime1
4y ago
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 PortableSec
115.
▲
by
mprime1
4y ago
I suppose that's a different implementation of the same 'hack' demo'd here, with the encryption carried out by an extension.
116.
▲
by
mprime1
4y ago
I'd be happy to see the wallet emptied. 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?
117.
▲
by
mprime1
4y ago
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
118.
▲
by
mprime1
4y ago
Thank you. > 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
119.
▲
by
mprime1
4y ago
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 extrac
120.
▲
by
mprime1
4y ago
Cool! Added a link to your project
More ›