61–70 of 385 posts
> I came up with Portable Secret on my own, but I have since found a few projects that do something similar.
> https://github.com/kaushalmeena/digi-cloak
> If you are aware of other similar projects, please let me know and I’ll link them here.
Digi-Cloak appears to be an in-browser steganography tool, but this project looks more like an encrypted pastebin (e.g., PrivateBin [1]).
This is password protected, so then an attacker must crack the password. The author exchanges the password over a phone call, which requires the password to be relatively weak, meaning the password is probably crackable. Exchanging the password via a second channel that the other user can copy and paste a more difficult password from to decyrpt the document might be more secure. The password may be more exposed, but…
Just was playing with this more. Visiting the secret's page from the "recently closed" or "history" views of Brave/Chrome leaves the password in text entry box. Edge doesn't do it. Probably there's some easy fix for it, I'd guess, but I'm not really a web dev.
Interesting, thanks for saying something. I'm also not a web dev, but I think I can manage to clear out the password once the secret is decrypted successfully.
Earlier quoted context omitted.
You are right, I'm conflating 2 issues. I'm pretty sure Brave was blocking window.crypto but can't remember if it was on a file or over plain HTTP
Blocking crypto on http:// is to spec (aside from localhost) and all the browsers do that. Blocking crypto on file:// is not to spec, and testing above ( https://news.ycombinator.com/item?id=34084526 ) none of the browsers do that.
All I remember is that I was developing the secret 'creator' code using Brave (my default unsecured browser) and at some point I had to switch to Safari (which I normally save for trusted websites only).
It's possible it was a red herring, and I switched browser but the problem was something else I did at the same time.
This is password protected, so then an attacker must crack the password. The author exchanges the password over a phone call, which requires the password to be relatively weak, meaning the password is probably crackable. Exchanging the password via a second channel that the other user can copy and paste a more difficult password from to decyrpt the document might be more secure. The password may be more exposed, but…
The big difference is that your project is self-contained in an HTML file, which I think is a much better design
Earlier quoted context omitted.
Code golfing is the act of finding ever and ever smaller, but functionally equivalent, expressions of a specific piece of code. Usually involves a lot of tricks specific to the language the golfing is done in. So yes, it would contain the PortableSecret minimized to such an extent that the whole thing fits in a QR-code (which has a practical upperlimit of a few KB?)
Gotcha. Thank you. IDK about including a full HTML into a QR code (how would you even open it? Wouldn't a reader get confused expecting a URL or plain string?) But... You can publish portable secrets on your website (just make sure they aren't advertised/linked/crawled) and then create a QR code of the (secret-by-obscurity) URL.
Earlier quoted context omitted.
The author recommends the use of XKCD correct-horse-battery-staple style passwords (aka diceware), which have a high ratio of entropy to ease of transmission effort. In other words they're relatively easy to exchange over a phone call but still secure.
And you can compose them from "pre shared" secrets. For example, the password hint for a secret I send to my sister: - The name of our neighbors cat - The name of your first boyfriend who scratched dad's car - Mom's nickname for aunt Ilda Concatenate those three with a dot. And voila, a pretty secure password without need of a side channel. (just made this up, I don't have a sister...)
"Live well, Laugh Often, Love Much"