有没有办法在不使用服务器端语言的情况下密码保护 HTML 页面？

Question

I have a series of interlinked web pages, and I want to restrict access to these pages by asking the user to provide a login and password. However, my hosting account currently does not provide any facility for server side scripting - is there any way I can accomplish this objective using only client side scripts?

I was wondering how the following program works -

http://www.myzips.com/software/HTML-Password.phtml

Clarification: Thanks for your inputs. However, if I am configuring the web server, then is there a possibility of the user entering an username and password?

Answer 1

There is no way to create a secure clientside script. If the user has access to it, it's insecure.

If your host is running apache you can secure folders using .htaccess, on IIS you can do the same through directory security.

Answer 2

Below is a working solution to this problem that uses encryption, which I implemented myself.

A few users here have suggested using an encryption-based approach to client-side password protection. I needed this functionality too, so I implemented it myself. The password is hashed using PBKDF2 and then used to encrypt the page with AES256.

The tool is hosted here:

https://www.maxlaumeister.com/pagecrypt/

with source code available here:

https://github.com/MaxLaumeister/pagecrypt

---

Description of the project, from the project page:

PageCrypt - Password Protect HTML

This tool lets you securely password-protect an HTML file. Unlike other password-protection tools, this tool:

1. Has no server-side components (this tool and its password-protected pages run entirely in javascript).

2. Uses strong encryption, so the password-protection cannot be bypassed.

All you need to do is choose an HTML file and a password, and your page will be password-protected.

Answer 3

You can create a file .htaccess with something like this :

AuthUserFile path/to/password.txt
AuthGroupFile /dev/null
AuthName "Acces Restreint"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>

You then have to create the .htpasswd file.

Answer 4

It is possible to implement this, although you'd probably find it easier to simply switch to a different hosting provider. Here's how it's possible:

First, encrypt the entire body with a symmetric encryption algorithm and a random key (the master key). Store this ciphertext in a javascript block as text.

For all your users, generate a javascript hash mapping their username onto an encrypted copy of the master key (encrypted with each users key).

Finally, create a web page asking for username and password. Once they're entered, use the username to locate the encrypted master key. Decrypt that with the password the user typed in and use the resulting master key to unlock the original body. Use javascript to replace the existing html body with the decrypted one.

Answer 5

I don't know about client side scripts but you can use the web server to restrict access to your site.
In IIS you can use "directory security" tab settings: configure IIS Web site authentication

Answer 6

If there was one and only one password for EVERYbody, you could try a public key-type approach. You could provide a simple script for performing RSA decryption (you'd need to do the original encryption somewhere where you have access to some type of programming software). Then, you could supply the content as an encrypted string. You'd display a password box, the user would type the password,then the string would be decrypted according to the password. If the password is correct, the string will decrypt correctly, and the page will show. Otherwise, the page will look like a bunch of garbage. Be careful, though, because this client-side method would be very vulnerable to brute-force.

Answer 7

Sure, if security is not a big deal. Essentially, you will be putting up a door that says "Please don't come in if you don't know the password". Anything that does not use server-side technology is likely using JavaScript, along with a file in a protected directory to store the passwords. This is not password protection, however. JavaScript can be disabled, which will cause the page to load. No doubt, this will be countered by hiding the content...but the content will still be viewable through the source. There are a few other ways, but if you have content that is truly worth protecting with a password, this is not a good way to go.

Answer 8

Yes it is possible but it's not very pretty or even very good.

• Your index page has an empty div where your restricted content will go.
• On page load or a link being clicked, a prompt (window.prompt) asks for your password.
• Your password is hashed and compared to a stored hash ( or array of hashes ) of the correct password in your script.
• If you have a match you load the content into the div via AJAX
• You could store the password in a cookie so it isn't prompted for each time ( not very secure but then this isn't a very secure system )

• You're still not all that secure because the filenames of the pages you'll be loading will be visible in your script but it might keep a very casual surfer out.
• You could obfusticate the urls thereby requiring some JavaScript knowledge to view. eg rot13

You will need a JavaScript hashing script

Answer 9

Or you could use a cryptic html-filename as the password and ajax in / browse to that page if it exists :-)

Just as secure (or unsecure) as the other suggestions, but probably easier to implement.

Answer 10

You don't need public key for this - in fact public key decryption is limited to encrypting other symmetric keys and certificates in practice because its computationally very expensive. You just need a shared secret.

Encrypt the webpages using AES (for instance), using a key derived from the passphrase (by hashing). You then have to securely communicate the pass phrase to the user(s) and write some javascript to download the encrypted content, prompt for a passphrase, decrypt the data and incorporate it into the DOM.

Its all rather messy and very brittle - only one password for all users, as soon as its compromised you have to replace the stuff on the server and hope against hope that google hasn't cached it... Suggest you move to a real ISP

As to the HTML password program you refer to, there's no way to know its not snake-oil or broken... The phrase "best security with strong algorithms" is not exactly encouraging!