[flagged]
The js is static too
Password protect a static HTML page
81–90 of 294 posts
Re: Password protect a static HTML page
#82The 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 iterations of PBKDF2[1]. This is magnitudes lower than what OWASP recommends[2].
I wouldn't personally put anything you want secure behind this.
[1]: https://github.com/robinmoisson/staticrypt/blob/5dac008ba644... [2]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
Re: Password protect a static HTML page
#83I'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".
> 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 remediation very well).
Re: Password protect a static HTML page
#84Earlier quoted context omitted.
I spent some time Googling this about 6 months ago. Lots of tutorials on Crypto-js, not so many (and almost zero "here's a super simple implementation") for WebCrypto API. I can understand if this is a hobby project why you'd lean into one rather than the other, I probably would have done the same.
Not going to pretend that I know what the most of the stuff mean, or if it is even safe enough, but I've followed the MDN articles and put together this TypeScript snippet [1]. Maybe somebody could comment on it? Also sorry for the long link. Is there any accepted way to post a shorted URL? Edit: added a corrected version [2] [1]: https://www.typescriptlang.org/play?#code/DYUwLgBAbiDGYHsBOE... [2]: https://www.typesc…
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 lot of people to use other AEADs like XChapoly, which has an extended nonce space that safely admits random nonces. Isn't cryptography fun?
Re: Password protect a static HTML page
#85[flagged]
funnily enough in certain circles "static pages" rather mean "static on server side" but "dynamic on client side".
Re: Password protect a static HTML page
#86Earlier quoted context omitted.
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".
> 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 of a bad implementation of CBC causing a security bug.
-------
I'd say you shouldn't implement your own GCM mode. GCM is quite complex, and the Galois Field's authentication bits could be side-channeled if you don't know what you're doing.
CBC? Where's the flaw? Its so stupid simple I don't think that even a novice would make a critical error.
Re: Password protect a static HTML page
#87Earlier 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…
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).
Re: Password protect a static HTML page
#88The 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
#89A more lightweight solution would be to hash the password and have a copy of that file at this url. windows.location = hash(password);
A more lightweight solution would be to let the Webserver (nginx, https, whatever) password-protect the site.
No JavaScript required a d highly efficient
Re: Password protect a static HTML page
#90Earlier 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…
You keep saying "the Galois Field" as if that was a thing. It's GCM. The components of GCM are CTR mode and the GMAC authentication code, which is based on GHASH. If you're afraid of Galois fields, you don't get to use AES at all! Nobody should be implementing any of these primitives themselves, very much including CBC, which, as you saw downthread, left both you and the author of this project with an insecure cryptosystem.
Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it!