181–190 of 294 posts
Earlier quoted context omitted.
Why not use a password protected word document if those are your use-cases?
You definitely could. But I think there are more computers with web browsers than there are computers that can read encrypted Microsoft Word documents.
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 thing…
https://ithemes.com/blog/what-is-the-htaccess-file/#password...
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 thing…
> This allows encrypting multiple page on a single domain with the same password
This might still work for you if putting everything on one page isn't a requirement. Using the "remember me" checkbox means the user only has to input this password once.
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?
TLDR: No. In fact, theoretically stretching the password is more effective than increasing iterations. However, I don't see him citing the fact some password hashing functions have limited input size, which means at some point having a larger password doesn't really change anything.
Earlier quoted context omitted.
I thought that too, but this appears like it works to password protect an html file that's *not* being served off a server. This ought to work with a file on disk too.
The more general solution is to use a password-protected archive.
By the way, I don't advocate for this idea. But still, I find it a pretty ingenious way to store encrypted data portably. Essentially what is happening is the file contains the encrypted data and the algorithm to decrypt it with the correct passphrase/key.
Use apache to serve your page and htpasswd to provide basic authentication. Easy 1994 answer
Also NGINX auth basic option. I use it on my personal website. https://docs.nginx.com/nginx/admin-guide/security-controls/c...
Whether using pbkdf2, argon2 or something else, along with what the work factor is, is critical to security in this application.
Earlier quoted context omitted.
Nobody implements GCM themselves; they get it from a library. CBC, implemented the way you're describing, is almost always insecure.
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…
Literally one of the most common things to fuck up when doing crypto yourself.