I had more simple and dumb approach in past.
Lets say you have some password like "super-secret".
Just place a secret "html" with content under the directory with the same name as your password. In public page have some prompt with password. When user enter password, you either redirect, dynamically inject iframe with your page. Since there is no way to list files/dirs of http server, it does pretty good job.
Password protect a static HTML page
231–240 of 294 posts
Re: Password protect a static HTML page
#232I had more simple and dumb approach in past. Lets say you have some password like "super-secret". Just place a secret "html" with content under the directory with the same name as your password. In public page have some prompt with password. When user enter password, you either redirect, dynamically inject iframe with your page. Since there is no way to list files/dirs of http server, it does pretty good job.
I wouldn't consider that awfully secure...
Your local browser will be saving your 'password' unencrypted in the cache and history, and maybe syncing to other devices.
Any workplace security system will probably be keeping records of your 'password'.
Any mistake on the web server could turn on directory listing, revealing the password.
Some other user of the web server, even a sandboxed low privilege process, will often have the ability to list directories.
Re: Password protect a static HTML page
#233I'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)
I don't know what "being a stream" has to do with anything (you should virtually always use "stream" modes of AES); the meaningful distinction between CBC and GCM is that GCM authenticates the ciphertext, so you can't tamper with it.
Also I checked the code quickly, they do Cbc-hmac, and they check the Mac before decrypting so it seems fine.
The 1000 rounds only of pbkdf2 on something that's essentially going to be available without any access control (since the encryption is the access control here) might be more annoying as the password can be human generated.
Re: Password protect a static HTML page
#234hmmm ... let me google that for you:
"The 'Basic' HTTP Authentication Scheme"
* https://www.rfc-editor.org/rfc/rfc7617
or
Re: Password protect a static HTML page
#235[deleted]
Re: Password protect a static HTML page
#236hmmm ... let me google that for you: "The 'Basic' HTTP Authentication Scheme" * https://www.rfc-editor.org/rfc/rfc7617 or * https://en.wikipedia.org/wiki/Basic_access_authentication
[deleted]
Re: Password protect a static HTML page
#237The 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?
I was thinking that I keep my secrets at hand in my password manager of the Keepass family. I sync the db from my laptop to my mobile devices.
The 100 characters password would be in the password manager but the secrets I would work with fit into the password manager, so I have no need to use a separate channel. I could upload the db, download it and just remember the master password.
The only use case for this technology is when the secret is the file itself and it can't fit in the password manager. An image, a file, etc.
Re: Password protect a static HTML page
#238hmmm ... let me google that for you: "The 'Basic' HTTP Authentication Scheme" * https://www.rfc-editor.org/rfc/rfc7617 or * https://en.wikipedia.org/wiki/Basic_access_authentication
[dead]
Re: Password protect a static HTML page
#239I'll echo the other sentiments here that I wouldn't consider this "static HTML", and I was expecting something about .htaccess. That said, this seems to be a strengthening of what used to be somewhat common "protection", namely variations consisting of: - Password in plaintext in the source e.g. "if(password=='hunter2') ..." - No correlation between password and page contents (either the content is merely hidden and…
> I wouldn't consider this "static HTML" why not? this could be served on a server which does not have any dynamic execution capabilities, and does not require the server to handle any other request other than just the HTML.
In my experience, that's normally called "static hosting", not "static HTML".
Re: Password protect a static HTML page
#240Earlier quoted context omitted.
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…
Your 128 key is difficult for users to enter manually.
Strong cryptographic keys should never be input using a keyboard and fingers, there are much better interfaces for that (security keys, passkeys, password managers).