Live data from Hacker News

Password protect a static HTML page

github.com

201–210 of 294 posts

Re: Password protect a static HTML page

#201
Phishing attachments/links abuse tools like this FYI, not impugning it in the least bit though.

It deters automated sandbox analysis by asking the user to use a password in the email body. For zip,pdf,etc... you can easily tell when they're encrypted and block/alert on them but not so with non-standard methods like this.

Re: Password protect a static HTML page

#202

I'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)

CBC is Cipher Block Chaining.

I think you might be referencing that the incorrect use of CBC leads to chosen-plaintext attacks, chosen-ciphertext attacks, or padding oracle attacks. GCM is AEAD, providing ciphertext authentication. [1]

For those reasons that you mention, use of encryption should always have a design review.

[1] https://en.wikipedia.org/wiki/Authenticated_encryption#Authe...

Re: Password protect a static HTML page

#203
post #78

Earlier quoted context omitted.

You mean, unless they tamper with the Javascript to capture the password (or the derived key).

I designed a similar tool with that threat model in mind: the resulting HTML/JS is as minimal as possible so it’s possible to inspect before entering the password. Of course assumes safe browser and client machine.. https://github.com/dividuum/html-vault

Kind of possible. With enough content, would you actually spot a "}; and some highly obfuscated code in the middle of the blob? (My guess is a no)

Re: Password protect a static HTML page

#204

Earlier quoted context omitted.

> CBC is far easier to implement... Never implement your own cryptography. Edit: In fact an incorrect implementation of CBC mode famously caused a vulnerability in Microsoft's ASP.NET in 2010 ( https://learn.microsoft.com/en-us/security-updates/securityb... ). The margin for error is small and even subtle mistakes or incorrect design can cripple security. Even Microsoft got it wrong once (although they handled remedi…

Or... you can have a more nuanced viewpoint and note that CBC is really, really, really easy to implement, and _really_ doesn't fall into that category of discussion. The reason you don't implement your own block ciphers is because side-channel attacks are damn near impossible for normal programmers to understand. Especially timing attacks. But block-modes of operation? Some of them are really easy. I've ever heard o…

[deleted]

Re: Password protect a static HTML page

#206

I'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)

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

You're misleading a lot of people with poor comments about implementation vs. design correctness. Design of systems that use crypto requires a specific kind of attention to detail.

Re: Password protect a static HTML page

#207

Earlier quoted context omitted.

BEAST and POODLE were both high profile attacks against how SSL used CBC.

But neither were attacks on CBC itself. That is to say: to "fix" BEAST or POODLE, you don't change a lick of CBC code at all.

[flagged]

Re: Password protect a static HTML page

#208
post #89

Earlier quoted context omitted.

A more lightweight solution would be to let the Webserver (nginx, https, whatever) password-protect the site. No JavaScript required a d highly efficient

Requiring some sort of VM or container to run this webserver on? Is it possible that's way more onerous than a static html file which can be emailed around? Are you sure nginx is even going to be around in, say, 15 years? (think password protected PDF but in html and allowing for JavaScript.)

> you sure nginx is even going to be around in, say, 15 years?

Considering it's been around longer than that, yes I think it will be around in 15 years

Re: Password protect a static HTML page

#209

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.

Re: Password protect a static HTML page

#210

Earlier quoted context omitted.

Padding is an important part of CBC.

[flagged]

> Furthermore, padding oracles are completely irrelevant to data at rest, like as described in this topics use case. So it really is a bit of a non sequitur too.

That's not true and extremely dangerous to say. In an offline, black-box scenario no server is needed for a padding-oracle. You are thinking of a side-channel oracle. A padding-oracle attack can absolutely be feasible in many cases.

Post reply on HN