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

151–160 of 294 posts

Re: Password protect a static HTML page

#151

Post by d-z-m »

tialaramex wrote: post #113
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…

Last I heard WebAuthn didn't have access to hmac-secret or prf outside of a Chrome canary. Has this changed recently?

Re: Password protect a static HTML page

#152

Post by tptacek »

ThePhysicist wrote: post #149
tptacek wrote: post #84

Earlier quoted context omitted.

If you call "encrypt" more than once in that code, you'll leak the authentication key. Every invocation of GCM encryption needs a unique nonce. Cryptography nerds will chastise you for using a random nonce (there theoretically isn't enough room in the GCM nonce space to safely encrypt large numbers of message with random nonces), but the alternative (using a counter) is even more hazardous. This problem motivates a l…

It's still considered safe to call AES-GCM with a single key and a randomly generated nonce 2^32 times [1], most practical systems don't come anywhere near this limit. And there's AES-GCM-SIV that solves nonce reuse (mostly), though it's not available in the Web Cryptography API at the moment. 1: https://csrc.nist.gov/csrc/media/Projects/crypto-publication...

I don't personally care, and probably wouldn't even sev:info a random GCM nonce in an assessment, but I would also choose extended-nonce Chapoly in preference to GCM in part because of this issue.

Re: Password protect a static HTML page

#157

Post by cuttysnark »

DanielBMarkham wrote: post #150
doodlesdev wrote: post #141

Earlier 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.

That the frontend is hosted on someone else's server is a convenience, but I see your point and agree. Technically nothing is uploaded anywhere, nor does it call any APIs to do the de/encryption. Instead, it uses the cryptography mechanisms built into your browser. Local file access and creation are via FileSystem api[0]. Said differently, you could save the page to your desktop—ensure all the includes are to local files, and still run it. In fact, thats's what I did with Portable Secret[1] which others noted was previously posted here. I can confirm this works and nothing "calls home".

[0] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem [1] https://mprimi.github.io/portable-secret

Re: Password protect a static HTML page

#160

Post by danShumway »

Hah, this is another thing I've been thinking about recently :) It's cool to see tools like this popping up.

An approach I've played around with, but never sat down to actually build, was to use service workers to be able to encrypt large sites -- the entire site would be encrypted locally from the command line using libsodium's `crypto_secretbox_easy`[0], and all of the data would be concatenated into a series of padded files to try and somewhat hide the number of files/size of the site. That key would be merged with a lookup table that would also be encrypted with a separate key, that would be stuck in the url hash. Then once the site was decrypted (ie, the secretbox key was sent to the service worker from the url) the service worker would intercept any requests the the front-end made and decrypt the original map that would tell it which file chunks to fetch, and then it would decrypt them on the fly and cache them for the duration of the session. Whenever you updated the site, the files would be re-encrypted with another key, but the "user facing" key in the URL would stay the same.

The linked project (and other projects people have linked) are a lot more portable, but I was thinking less about being able to have a single file that I carried around and more about being able to put up a full website where I could have something approximating user accounts (ie, possibly having multiple lookup tables that could be decrypted separately per-user), and where I could build full-featured projects that could fetch their own resources.

But, I haven't ever gotten around to actually building it, I only ever built some tests to make sure that it would technically work, and I got nervous about rolling my own solution even though I was just going through the libsodium APIs.

----

[0]: I've seen a couple of people recommend using Web Crypto instead, which I've avoided because I thought libsodium ported to the browser was harder to shoot myself in the foot with; is that a bad instinct?

Post reply on HN