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

131–140 of 294 posts

Re: Password protect a static HTML page

#131

Post by dymk »

superkuh wrote: post #3

If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. Using a dynamic script or application to generate a static html page that requires no JS execution is a static…

Title is still accurate, the tool is for password protecting a static HTML page. The page starts out as a static HTML page. Then this tool generates something that has password protected it.

Re: Password protect a static HTML page

#132

Post by Karellen »

layer8 wrote: post #117
Karellen wrote: post #67

Earlier quoted context omitted.

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.

I was thinking of editing my comment to add "Or be able to support filetypes other than HTML", but I suppose in our glorious "everything is the browser" future, filetypes other than HTML are as anachronistic as 8" floppy disks.

Sigh.

Re: Password protect a static HTML page

#133

Post by tptacek »

majou wrote: post #130
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…

From what I shallowly researched; GCM's nonce seems limited to 12 bytes by convention only. That nonce reuse is so fatal seems absurd to me. Would "salting" the key safely tackle the problem? Put explicitly; send decrypt(ciphertext, nonce, pbkdf(pass) || salt) [edit: apply salt outside of the kdf]

As I remember it, the balance of the bytes in the AES block are used for the counter. At any rate, the convention is essentially universal.

Re: Password protect a static HTML page

#135

Post by eduction »

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 unless you also archive the password, which must be done out of band

-this doesn’t compose or integrate with the web: none of the common tools you would use to download, spider, archive, spindle, mutilate web pages know how to deal with this

It’s certainly one solution. The http basic auth built into every popular webserver is another, with none of the above limitations. But I guess that would require spending 5 minutes learning and implementing some server config, and why do that when you can further ruin the web by shoving yet more user hostile complexity into client side JavaScript.

Sorry to sound bitter I just feel this is a really bad idea if you think about it for any length of time.

Re: Password protect a static HTML page

#136

Post by [deleted] »

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…

[deleted]

Re: Password protect a static HTML page

#137

Post by dakiol »

eduction wrote: post #135

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…

> The http basic auth built into every popular webserver is another, with none of the above limitations.

The obvious advantage of OP's approach is that one doesn't need to control the server that serves the HTML (e.g., static site served via GitHub pages would be enough)

Re: Password protect a static HTML page

#138

Post by dakiol »

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…

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

Re: Password protect a static HTML page

#139

Post by majou »

tptacek wrote: post #133
majou wrote: post #130

Earlier quoted context omitted.

From what I shallowly researched; GCM's nonce seems limited to 12 bytes by convention only. That nonce reuse is so fatal seems absurd to me. Would "salting" the key safely tackle the problem? Put explicitly; send decrypt(ciphertext, nonce, pbkdf(pass) || salt) [edit: apply salt outside of the kdf]

As I remember it, the balance of the bytes in the AES block are used for the counter. At any rate, the convention is essentially universal.

Sounds above my (current) head.

Here I thought GCM was some modern foolproof/footgunless design.

Re: Password protect a static HTML page

#140

Post by cozzyd »

pyrolistical wrote: post #27
hosteur wrote: post #19

Earlier quoted context omitted.

Wow I like that. So simple and elegant. Could be combined with a username to produce unique urls per user.

A miss configured http server that allows directory listing would compromise everything. Also now all intermediate things that have access to the hashed url would suddenly have access to a secure piece of information. Don’t be clever with security

You can always put an index.html to prevent that mistake.
Post reply on HN