Anywhere that you trust, and where the page is hosted securely. For example, a malicious hosting service could alter the password prompt. Or the page as a whole could be put in a frame with a transparent overlay.
That felt implicitly obvious to me, but I think you're right and it wouldn't hurt to put those assumptions in the FAQ. Thanks for the feedback!
(If you, or someone else, see other attack vectors, feel free to comment with those)
Happy to answer any question you might have, and feel free to offer feedback too.
(Last time this got posted to HN[1] was really productive in improving the project, thanks!)
> I was wondering why I was seeing plenty of people from github on my meditation website so I checked HN, hi!
I'm curious: how did you notice this? You happened to be viewing your website stats or your analytics tool was setup to notify you when you receive a surge of traffic :)?
I recently launched another project with an interface to search and filter blog posts from a prolific blogger I really like, using AI tech. He featured the website on his blog last week which draw a pretty big spike in traffic - well, big for me, like a few thousands people - so I've been refreshing my analytics tools from time to time to follow what's happening, and I just noticed a spike on my other website as well.
[1] https://github.com/robinmoisson/staticrypt#community-and-alt...
I saw that StatiCrypt is listed is the alternative section of your README, I'll do the same on StatiCrypt (and add a bunch of the one listed there that I didn't know about!)
The "Alternatives" section of StatiCrypt has always felt a bit empty to me, I'm glad to discover all those great looking projects and beef it up a bit. :)
I’m the ‘maintainer’ but I’m hands off and not planning on significant improvements.
Discussion on HN was also quite interesting and you may find some ideas: https://news.ycombinator.com/item?id=34083366
I also recently presented this at HOPE(.net) and was very well received by a technical crowd so congrats on independently inventing the same thing ;-)
It has some valid other use cases but it has drawbacks too and htpasswd can definitely be the better solution in many situations. StatiCrypt just aims at being another tool with different trade-offs.
https://github.com/blackhillsinfosec/skyhook
Round-trip encrypted file transfer. Uses WASM to decrypt files on the client side.
Aims to bypass IDS.
It wraps a JS implementation of only the decryption side of GPG symmetric encryption, so there's less opportunity for the tool itself to introduce security errors.
Do you mind if I list in the Community and Alternatives[1] section of the StatiCrypt readme?
[1] https://github.com/robinmoisson/staticrypt#community-and-alt...
If you're open to sharing what didn't work for you in remembering people through re-deploy I'd love to hear it, I spent quite a few brain-cycles to think about making that as seamless as possible for the user (semver major version bump shouldn't break this, for example).
I'm assuming the problem is the salt being changed if it's not pinned by the .staticrypt.json file (auto-created but needs to be commited) or the `-s <salt>` CLI option.
Would you be okay with me listing your project in the Community and Alternatives[1] section of the StatiCrypt readme?
[1] https://github.com/robinmoisson/staticrypt#community-and-alt...
There's a (warning: very detailed) issue covering the topic of PBKDF2 iterations and password length over here, if you feel like diving into that rabbit hole: https://github.com/robinmoisson/staticrypt/issues/159
The old school way is comparing the top level URL with JS and redirecting but there are ways to deal with that