Password protect a static HTML page, decrypted in-browser in JavaScript
github.com> 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.
Clickjacking has been a solved problem for over a decade. Set X-Frame-Options: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
Hence the need for a hosting service that you trust. You can't force that header on an untrusted server.
How do I set this in a shared hosting environment like GoDaddy?
You can set a CSP in the HTML head section using a meta http-equiv tag. It has similar functionality to X-frame-options IIRC.
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
is it not by default? If no, then i would consider it as a bad design.
or even better CSP options no?
(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
Would it help to employ the ssl cert in the encryption/decryption process and use it as an IV or so?
No. The attacker can mock that just as easily.
Author here. I was wondering why I was seeing plenty of people from github on my meditation website so I checked HN, hi!
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!)
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 :)?
Just random chance!
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
Love that approach! Would you be ok with me featuring it in the Community and Alternatives[1] section of the StatiCrypt readme?
[1] https://github.com/robinmoisson/staticrypt#community-and-alt...
Sure
Similar project that supports files: https://github.com/mprimi/portable-secret
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. :)
Thank you for the link GP!
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 ;-)
The maintainer is https://news.ycombinator.com/user?id=mprime1
In the old days, we used .htaccess and htpasswd for that.
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.
Reminds me of one of my projects:
https://github.com/blackhillsinfosec/skyhook
Round-trip encrypted file transfer. Uses WASM to decrypt files on the client side.
Aims to bypass IDS.
Similar (but also for a narrower use case with fewer features): https://github.com/sowbug/quaid
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.
That looks cool!
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...
Go right ahead. Thanks!
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)
Glad you enjoyed it before switching!
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.
Looks cool! And I like the effort you put in making your readme clear and covering many possible configs too, it feels very easy to read to me.
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...
I didn't make this :)
Then I'll go ahead and list it there. Thank you for sharing the project!
How long should the password be to make this safe from brute force attack?
The FAQ recommends a minimum of 16 chars. Obviously it depends on your threat model.
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).
So you're looking for an authentication and authorization system.
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.
As an alternative, your content can be stored statically on a request path that is the hash value of a secret