211–220 of 294 posts
Here's an example of protected page saved with SingleFileZ: https://gildas-lormeau.github.io/private/ (password: thisisapage)
Wouldn't .htaccess solve this issue?
Hey look it’s a “static” HTML file that decrypts itself using AES 256 CBC. Sure, that sounds static and simple and good for the web. What could go wrong. Some obvious limitations: -requires users to re-authenticate for every protected file on your site -assets loaded by the page not password protected -uses a single password globally shared by everyone who wants to read the doc -archiving the page itself is useless u…
This also works without a webserver. It can be a local file that is opened in a browser.
Earlier quoted context omitted.
And the library they use doesn't have GCM mode. So now what? https://cryptojs.gitbook.io/docs/ Because CBC mode is easier to implement, you'll find it in far more libraries. And honestly, if your underlying block-cipher is secure (that's the hard part: where your side-channels all exist), then CBC mode is really the easy part and can be safely implemented yourself. It really is that simple. ----------------- CBC does…
It’s unclear why you’re being so flippant about “adding on HMAC.” The things you are describing are difficult and dangerous for developers to build.
HTML uses some Javascript to encrypt a file. Then later, the Javascript decrypts the file and returns it to normal.
This is a "beginner level" cryptography situation. Yes, I know there's all sorts of traps all around the field of cryptography. But I also know that this particular use case is simple enough that beginners can try their hand at it, and probably make something useful. And with low-probability of a critical error.
-------------
Don't write your own AES-GCM implementation. Don't write your own TLS1.2 implementation. Etc. etc. There's all kinds of subtle errors involved. IVs, Padding, side-channels, man-in-the-middle... more than I can count and very subtle to think about.
The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ to the use-case discussed in this github is proof enough. The community is a bit rabid over its "advice" on this subject.
Gad! I have spent all morning trying to --- password protect a static html page. How in the hell does HN have a story about the exact topic I've been struggling with appear just a dozen or so hours after I started working on it. Wow. I was _extremely_ happy to see this posted. However when I click the link I am taken to the library I had initially tried and had to reject. Without getting into the crypto side of thing…
If your server supports it, a fast and easy way to password protect a page is to put it in a folder and password protect that folder with htaccess: https://ithemes.com/blog/what-is-the-htaccess-file/#password...
Earlier quoted context omitted.
[flagged]
> Furthermore, padding oracles are completely irrelevant to data at rest, like as described in this topics use case. So it really is a bit of a non sequitur too. That's not true and extremely dangerous to say. In an offline, black-box scenario no server is needed for a padding-oracle. You are thinking of a side-channel oracle. A padding-oracle attack can absolutely be feasible in many cases.
You're right that its possible that an offline decryption algorithm could in fact be a padding oracle under the right scenario. But I still posit it probably doesn't apply to this static-HTML page generator.
Bad idea. Your browser comes with web crypto, including AES256 and PBKDF2. See MDN.
Earlier quoted context omitted.
If that's wrong, so is the name of every "static site generator". Also: please don't make the same point in two separate top-level comments.
A static site generator can be used to create an .html file that's dependent on the user to execute a javscript web application to show the content. That makes that generated page dynamic. It doesn't change the nature of the static site generator.
My recent solution to this problem -- for an entire static site -- was to use HTTP Basic authentication with CloudFlare Pages: https://github.com/garrison/cloudflare-pages-shared-password
I was digging through the comments for someone to point this out. I’m honestly curious why people are using these overly complex options when a solution has been built into the HTTP standard for decades (and, in fact, is heavily abused for many APIs). And it’s superior in many ways, since the file is never delivered until authentication has been completed.
This means you must have a secondary channel to communicate to the user about the password, and the server must also know the password.
So depending on your use-case, the basic auth isn't suitable. For example, mega : https://en.wikipedia.org/wiki/Mega_(service) , in which you want to ensure that the decrypted data is _not_ accessible to the server, so the key is not stored nor sent to the server!