> returns a static HTML page showing a password prompt that you can now safely upload anywhere
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.
Alas, no. ‘frame-ancestors’ does not work in meta. There is no reliable way to prevent click jacking if you are just editing the HTML. That makes sense: in order for these meta directives to even be enacted the HTML will have already begun to download and be parsed.
The old school way is comparing the top level URL with JS and redirecting but there are ways to deal with that
(author here) Yeah, or if it's on http someone could MITM and change the script, or if they are malicious extension on the browser the content can be stolen after decryption.
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)
a supply-chain attack where malicious JS is delivered to the user (even from your own server, as the author of the software, maybe you got hacked yourself for example) is another way
Well done on getting your project linked here again on HN.
> 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.
Built the same thing, but with a slightly different focus: Have the result as small as possible, so assuming you can trust your browser you can audit the received HTML file prior to entering your password: https://github.com/dividuum/html-vault
Oh cool that looks awesome thanks for sharing! Are you the maintainer?
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. :)
Yeah definitely! StatiCrypt was originally created to password protect pages uploaded on static hosting (like Github pages) or where you didn't have control on the server.
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.
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.
I used this before and it was really decent, actually had it as a build step on some dev preview stuff. Only moved to basic auth because getting it to remember people through re-deploys was a faff so it became annoying when it wasn’t working (I’m aware it has a solution to this problem but it wasn’t really working for me easily)
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.
Another interesting project allows you to do a similar thing with Hugo. I'm a bit nervous to use these myself but seems useful for some limited, non-serious use cases.
Especially with 600k PDBKF2 iterations, 16 alphanum chars should be very safe.
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
Nice project. There should be some project which standardizes a mechanism to do that that with a browser extension. This would make it possible to share websites without trusting the web hoster.
This is what I'm looking for: a way to put something in public (I'm using Vercel) that "only" me can access (anybody who can decrypt it doesn't need the content that I encrypt).
That's incorrect: I'm looking for a tool that takes a html page, encrypts the content, generates another html page which has some js to decrypt what was encrypted before and puts the decrypted content back in the body of the html page.
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.