I would just use tweetnacl's secretbox for this instead of custom crypto.
Password protect a static HTML page
271–280 of 294 posts
Re: Password protect a static HTML page
#272Does anybody know if image resources also is encrypted or is it just the html content?
Re: Password protect a static HTML page
#273Earlier quoted context omitted.
> What am I supposed to tell a young programmer who is interested in playing around with encryption on their own? Tell them to stop if they’re trying to do it for anything real, or do it as a toy protect that never sees the light of day. And if they select the latter, then they may as well try GCM. Tell them to leave encryption writing to the professionals.
This entire subthread started because the github repo here used CBC mode (which was supported by the original writer's crypto library), rather than GCM mode (which was unsupported). We're well deep into a "professional" discussion about the pros and cons of particular implementation details of cryptography. ------------ Go back to the top. Look at the Github code. See that it uses a crypto-library. What should have t…
This GCM sideshow is a consequence of the project using crypto-js, which is not fit for purpose. If your cryptography library doesn't support any AEADs, replace it with one that does. This is a browser project, so all it actually needs is WebCrypto. The whole discussion on this thread has been super weird. Don't ever encrypt with non-authenticated cipher modes.
Re: Password protect a static HTML page
#274Earlier quoted context omitted.
Which in turn has inspired the creation of PrivacyProtect [0]. It allows to do basically the same thing as the other applications, but in my opinion the interface is better, it also allows you to directly select a file which I guess is easier than copying the contents, it also means you can just select an image file for instance or some other type of file other than a web page. [0]: https://www.privacyprotect.dev/
Why is everybody forcing me to upload to the web the very files I want to keep private to myself? If any code in the universe should run locally, it's this kind of code. I don't get it. Great UI, though. But I still don't get it.
> Why is everybody forcing me to upload to the web the very files I want to keep private to myself?
This isn't the use-case I had in mind.
My personal one: I want to build a small utility web app for a very specific task, and it would be used by me and by some of my friends (less than 10 users total). The entire thing can easily be front-end code, which is nice, because I can just host it on Netlify and not bother with hosting, managing it, etc., thus making the complexity of it all much lower.
But there is one catch - the web app uses an external API, and, along with it, the API access key. This puts a big stop sign for making it front-end only. And I don't want to up the level of complexity by managing the back-end just for the API access key retrieval (for a webapp used by less than 10 people). Exposing the API key in the front-end code on a publicly accessible website is one of the worst ideas I can think of.
I haven't done the evaluation on how well the solution in the OP would serve my specific purpose, but it looks promising.
Re: Password protect a static HTML page
#275Earlier quoted context omitted.
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.
with basic authentication, you cannot embed the decryption key into the url via a hash fragment. 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 _no…
Sure you can, it’s been built-in to the HTTP spec since RFC1738[1]. You just do:
//:@[:][/]/
It doesn’t work on IE classic, but should still be perfectly valid on Chrome, Safari, Firefox, etc.
Re: Password protect a static HTML page
#276Earlier quoted context omitted.
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.
Author here - the specific use case is when you _don't_ have or want server-side logic or a DB. For example on static hosting (hence the name StatiCrypt) like Github pages, Netlify, etc. That means nothing to maintain, no server cost, no serverless functions to rely on, etc. But when that's not a constraint there are many different options that might make more sense.
Sure, I’ll give you that use case.
It’s just weird how many people are jumping on this as some new technique when Basic Auth is fully usable in many other cases.
Re: Password protect a static HTML page
#277I'm not a cryptographer, but I'm pretty sure that CBC ( https://github.com/robinmoisson/staticrypt/blob/main/lib/cry... ) should be replaced with GCM ( https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... ) since this is not a stream. https://security.stackexchange.com/questions/184305/why-woul... (also, use the built-in WebCrypto API instead of the crypto-js package)
Leave it to full-stack devs to take care of cryptography
As a newer dev later in life, I love to learn about inter-disciplinary snobbery/riffing. I learned some of what I know from a full stack dev, who was convinced anyone who couldnt do everything "was shit" and "should be something easier like a web developer or IT guy" instead. I'm excited to learn that pure disciplines also look down on full stack devs
Re: Password protect a static HTML page
#278The use case for a document like this is a little different from .htaccess. This is something you can share, email, host, etc and have some security in transit and at rest. Yes, .htaccess password protects on the web server, but that is one specific use case and requires a lot of machinery and specific environment. JavaScript is everywhere. And this is a static HTML document in the sense that there is no server side…
I'm not seeing much of a use case tbh, in the sense that I cannot see myself going for something like this. If it's really sensitive I wouldn't put it on an accessible page and then have to worry about password sharing, server-side security/possible spoofing, etc etc So if I can share the password securely and/or have it somewhere safe, why don't I use that system for the content itself? because of html formatting, s…
I would not use this for anything. Existing tools are better in every way. It is a cool idea though.
Re: Password protect a static HTML page
#279Earlier quoted context omitted.
Why not use a password protected word document if those are your use-cases?
But doesn't Word use CBC? Apparently from upthread that's E_ALWAYS_BAD.
Ahh, well, this is actually a field where I know a lot.
Since it is my job. Let me distill up thread.
1. Don’t implement the underlying crypto yourself
2. CBC is hard to get right
3. There are a lot of esoteric attacks and if you have a nation state attacking you they could exploit them, but they won’t because they will just put some crap on your systems and do it easier.
Also this is a very simple use case to get authenticated CBC correct with. So, the real answer is “don’t do this, but it is probably okay in this one use case, assuming they didn’t implement all of this themselves (e.g the crypto algorithms themselves)
You should still listen to tptacek though. Use an authenticated crypto mode :)
Re: Password protect a static HTML page
#280Earlier quoted context omitted.
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...
Keep in mind the same server will lock you out for a day or so if you autofill the wrong password, be warned. :D
This could be true if the server is using something like fail2ban.