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

111–120 of 294 posts

Re: Password protect a static HTML page

#111

Post by efrecon »

victorbjorklund wrote: post #97

Wow. This is really cool. I wonder if it would be possible to kind of build a site with personal pages etc for different user each encrypted by their own password Like domain.com/user1 and domain.com/user2 each are encrypted but with their own passwords. So user 1 can only visit his own page and not other users. (I know there would be much easier to just do a traditional webapp but as a concept it is super cool).

I am using it in exactly that context and it is good enough for the level of security I need to achieve. I understand this can be brute forced, but this is a risk I am willing to take given the level of "secrecy" of the content.

Re: Password protect a static HTML page

#113

Post by tialaramex »

VoidWhisperer wrote: post #82

The downside to this method is that since the resulting cryptographic hash and salt have to be in the resulting file, so there is nothing stopping someone from pulling the hash/salt out and bruteforcing it locally (as opposed to being able to ratelimit login attempts on a server) if they are so inclined and have the required resources.. which may not be that much in the way of resources as the tool uses 1000 iteratio…

Right but all that's happening here is stretching. So the difference only matters in the middle. Regardless of the strategy bad guys will guess "1234" or "sesame" (too easy) and they won't guess a random 128-bit key I just generated with my hexadecimal dice (impossible). This weakness only means it's easier than expected to guess your password is "suckitelon" or "GoCowboys1978" or whatever

We put a lot of effort into teaching people to do better stretching, but it feels like the result was they put even more passwords on things, rather than using the breathing room to get off passwords. If your project for 2023 is "Use a fancier password hash" instead of "Get rid of passwords" you are Doing It Wrong™.

If you wanted to do something like this seriously, consider hmac-secret extension to FIDO, which means Security Keys (so the things you'd use to log in to say Google or Facebook) can present an arbitrary always-identical secret value which would be more than adequate to secure such a thing unlike a human memorable password. Today hmac-secret is mostly used to authenticate to an off-line laptop PC or similar.

Re: Password protect a static HTML page

#114

Post by DanielBMarkham »

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 things (which very well may resolve to "just make it tough enough for most folks") I crashed and burned using this tool once my page reached certain sizes. (I was cramming everything I needed into one page and I had a big hunk of bytes that I didn't want hanging out on the filesystem)

As I understand it, this is a known issue in V8. V8 limits the number of properties/collection members an object can have. There's a flag you can use with node to get a little more headspace, I believe it's something like "--max-old-space-size=8192" but it's a V8 problem, not a node problem. The staticrypt coders could also switch to a streaming cryptography instead of block, but that's far too much to ask of the casual user who only wants to lock up a page or two.

This is a really cool tool, and I wished I could have used it. Good luck to the team going forward. I've gotta find something else as this doesn't work for me.

Re: Password protect a static HTML page

#115

Post by fifafu »

tptacek wrote: post #87
dragontamer wrote: post #80

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…

So use WebCrypto, instead of the cabinet of curiosities that is crypto-js. (Or, better yet, don't do stuff like this at all, because a browser window is simply an awful setting for serious cryptography).

WebCrypto only works in secure contexts which is a significant limitation (https origins only)

Re: Password protect a static HTML page

#116

Post by fifafu »

realPubkey wrote: post #15

Should have used the WebCrypto API instead of the crypto-js npm package. https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...

WebCrypto only works in secure contexts (https), which is a significant limitation for some use cases. But I agree it should be an option.

Re: Password protect a static HTML page

#117

Post by layer8 »

Karellen wrote: post #67
Dma54rhs wrote: post #52

Earlier quoted context omitted.

You can email or hand out physical copies on usb would be one use case where server auth can't compete.

Aren't existing encryption tools more flexible for sending out copies via those methods? e.g. by making more cipher suites available? Or by allowing you to encrypt with the intended recipients' public keys, so you don't need to worry about distributing the passphrase securely? And might allow better integration with password managers, as the OS would recognise the files as being encrypted?

Supposedly browsers are more ubiquitous on the recipient side than whatever other tools you might use.

Re: Password protect a static HTML page

#118

Post by tptacek »

fifafu wrote: post #115
tptacek wrote: post #87

Earlier quoted context omitted.

So use WebCrypto, instead of the cabinet of curiosities that is crypto-js. (Or, better yet, don't do stuff like this at all, because a browser window is simply an awful setting for serious cryptography).

WebCrypto only works in secure contexts which is a significant limitation (https origins only)

Your next best bet might be sjcl.
Post reply on HN