Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password protect a static HTML page

github.com

Post reply on HN
Print view View original

251–260 of 294 posts

Re: Password protect a static HTML page

#251

Post by int0x2e »

tptacek wrote: post #76
dragontamer wrote: post #72

Earlier quoted context omitted.

CBC is far easier to implement than GCM mode. I bet that most programmers cannot implement a Galois Field in Javascript. Meanwhile, CBC is just "encrypt then xor".

Nobody implements GCM themselves; they get it from a library. CBC, implemented the way you're describing, is almost always insecure.

As the old quote goes - "if you are typing "AES" into your code at any point, and you are not a world-renowned crypto expert - you will get this wrong, guaranteed". There are so few cases of people who are not seasoned crypto engineers getting everything 100% correct that it's basically a myth, and in crypto, getting things "almost right" is the same as getting them wrong...

I too loved playing with crypto - read a ton of books, attended some crypto classes in University, implemented some crypto systems which I thought were secure, etc. - but nowadays I wouldn't dare use anything that isn't considered secure by a large audience unless I had extremely good reason to do so.

Re: Password protect a static HTML page

#252

Post by yoble »

deaddodo wrote: post #209
garrison wrote: post #175

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.

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.

Re: Password protect a static HTML page

#254

Post by mov_eax_ecx »

KronisLV wrote: post #247
johannes1234321 wrote: post #7

Earlier quoted context omitted.

Those would be quite nice, if web browsers were good HTTP clients. The user experience with basic auth is not so good. The dialogs give little way to customize and providing information for user. No support for logout or any form of password changes.

> The user experience with basic auth is not so good. Apache actually also has an OpenID Connect module (it's certified and everything), which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/…

IdentityServer have a Community Edition that is suitable for OSS projects.

Re: Password protect a static HTML page

#255

Post by fluidcruft »

ipaddr wrote: post #163
bitexploder wrote: post #16

The 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…

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.

Re: Password protect a static HTML page

#256

Post by KronisLV »

mov_eax_ecx wrote: post #254
KronisLV wrote: post #247

Earlier quoted context omitted.

> The user experience with basic auth is not so good. Apache actually also has an OpenID Connect module (it's certified and everything), which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/…

IdentityServer have a Community Edition that is suitable for OSS projects.

Hmm, from what I can tell, this appears to be sort of true: https://duendesoftware.com/products/CommunityEdition

However it's the kind of license that's gated behind a manual signup:

> If you would like to request a Community Edition license, please provide:

> Confirmation that you understood the qualifying criteria

> Your category (for-profit, non-profit, charity)

> Your (company) name

> Your address

> Your contact email

This seems to be reflected in that you cannot find any official Docker images, for example: https://hub.docker.com/search?q=identityserver

Contrast that to: https://hub.docker.com/r/keycloak/keycloak (admittedly, the Bitnami containers are better, since those provide good documentation right in Docker Hub, instead of being lazy like Keycloak did and just putting it on their site)

Overall, the licensing situation with IdentityServer seems interesting, perhaps a bit more restrictive than Keycloak or other competitors: https://leastprivilege.com/2020/10/01/the-future-of-identity...

Regardless, to me being able to download software without messing about with signups and justifying why I need it feels like a good litmus test for some of the culture and community behind it. Regardless, I don't think that there are any truly excellent solutions in this space out there.

Then again, you see basically the same with the likes of OpenLDAP, FreeIPA and others that still don't quite compete with Microsoft's AD. There's a lot of problems (identity and device management, authentication/authorization gateways etc.) that could have great OSS solutions for them, if at the end of the day everything didn't circle back to money. Oh well.

Re: Password protect a static HTML page

#257

Post by mov_eax_ecx »

It IS a bad idea. 1) The attacker get access to the server and changes the file on the server, one that writes an html/js that redirects to https://example.com/malicious.html with the same interface and captures your secret password. Proceeds to access your file with your password.

2) The code calls back home in xhr.open('POST', 'https://zlgpaemmniviswibzuwt.supabase.co/rest/v1/rpc/increme...', true); i don't want YOU to know when i open a file, or encrypt a file.

3) The surface attack of the browser is HUGE, there are many escape the sandbox vulns, same origin bypass, zero day exploits that can be exploited, take a look at the cve database of chromium, using the browser the way it is proposed is a big mistake.

Finally, the code is not audited, may have cryptographic weakness as pointed in other comments. The solution you made could be good for a class assignment, or to learn how to use cryptojs, but from the security standpoint is a mistake to use it for anything serious.

If you are security conscious, you should use VeraCrypt/bitlocker, a simple rar/zip with password, even a pdf/.docx with password, or use a secure server with SSL, sftp?.

Re: Password protect a static HTML page

#258

Post by muyuu »

bitexploder wrote: post #16

The 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, storage, etc? seems like a much easier problem to solve than the threat model of sensitive stuff shared on the web.

I'm trying to imagine concrete situations that I'd go for something like this and I cannot quite think of any. Silo-ing stuff behind a login is so much more versatile. Generally not putting sensitive stuff on the web works so well when you can send essentially anything point-to-point using so many widely used protocols including Signal, LINE or Whatsapp, or a simple email, which you can use to send encrypted 7z files for good measure.

Re: Password protect a static HTML page

#259

Post by k3vinw »

sowbug wrote: post #107
anurag wrote: post #91

Pagecrypt does the same thing, but with the Web Crypto API. More (including a sample repo) at https://render.com/blog/static-site-auth-pagecrypt .

Similar here: https://github.com/sowbug/quaid It works with a GPG-encrypted file. I figured that was safer than developing my own encryption format. As it is, any vulnerability in the decryption process is equivalent to a vulnerability in GPG.

Thanks for creating this. I was just thinking why not use gpg for this?

Re: Password protect a static HTML page

#260

Post by jsjohnst »

bawolff wrote: post #191
dakiol wrote: post #138

Earlier quoted context omitted.

Is it a downside if the password is a 100 characters-long string?

Depends which characters they are. But in practise nobody uses 100 character long strings. Security is the intersection of real users with systems, not imaginary ones.

> But in practise nobody uses 100 character long strings.

Multiple websites I use daily have that length of password or longer.

Post reply on HN