Related
When I want to put a login system in place, I always compare the MD5 of the given password with its value in the users table on the server side.
However, a friend of mine told me that a "clear" password could be sniffed by a network software.
So my question is: is it a good idea to hash the password on the client side? Is it better than hashing it on the server side?
Basically, your friend is right. But simply hashing the password on the client side is only just better than submitting it as plain text to the server. Someone, who can listen for your plain text passwords is certainly also able to listen for hashed passwords, and use these captured hashes him/herself to authenticate against your server.
For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.
On the server:
generate a few bits of random
send these bits (in clear text) to the client
On the client:
generate a few random bits
concatenate password, the server's random bits and the client random bits
generate hash of the above
submit random bits(in clear text) and hash to the server
As the server knows its own random information as well as the client's random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used...), as long as both parties generate different "noise bits" each time, the hand shake is performed.
Edit All of this is error prone and tedious and somewhat hard to get right (read: secure). If ever possible, consider using authentication protocol implementations already written by knowledgeable people (unlike me! The above is only from memory of a book I read some time ago.) You really don't want to write this yourself usually.
First of all, this does NOT improve the security of your application (assuming it is a web app).
Use SSL (Or actually TLS, which is commonly called SSL). It is free and easy to set up with Certbot.
The why to this is simple. TLS solves a problem (when used with a certificate from a certificate authority, not self signed) that is quite big in cryptography: How do I know the server I am talking to is the server I think I am talking to? TLS Certificates are a way of saying: "Me, the certificate authority, trusted by your browser, certifies that the website at [url] has this public key, with a corresponding private key, which (private key) only the server knows, look I signed my signature all over the document, if anyone altered it you can see".
Without TLS, any encryption becomes pointless, because if I sit next to you in a coffeeshop, I can make your laptop/smartphone think I am the server and MiTM (Man in The Middle) you. With TLS, your laptop/smartphone will scream "UNTRUSTED CONNECTION", because I don't have a certificate authority signed certificate that matches your site. (Encryption vs. Authentication).
Disclaimer: users tend to click right through these warnings: "Untrusted connection? What? I just want my pictures of kittens! Add Exception Click Confirm Click YAY! Kittens!"
However, if you really do not want to use a certificate, still DO implement client side Javascript hashing (and use the Stanford library (SJCL) for that, NEVER IMPLEMENT CRYPTO YOURSELF).
Why? Password reuse! I can steal your session cookie (which allows me to pretend to your server that I am you) without HTTPS easily (see Firesheep). However if you add Javascript to your login page which, before sending, hashes your password (use SHA256, or even better, use SHA256, send them a public key you generated and then encrypt hashed the password with that, you cannot use a salt with this), and then sends the hashed/encrypted password to the server. REHASH the hash on your server with a salt and compare that to what is stored in your database (store the password like this:
(SHA256(SHA256(password)+salt))
(save the salt as plaintext in the database as well)). And send your password like this:
RSA_With_Public_Key(SHA256(password))
and check your password like this:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Because, IF someone is sniffing your client, they will be able to login as your client (session hijacking) but they will NEVER see the plaintext password (unless they alter your Javascript. However, a Starbucks hacker will probably not know how or be interested in this.) So they will gain access to your webapp, but not to their email/Facebook/etc. (for which your users will likely use the same password). (The email address will either be their login name or will be found in their profile/settings on your web app).
Actually I disagree that client side hashing is more secure in this case. I think it's less secure.
The entire point of storing a hash of the password in your database as opposed to the real password (or even an encrypted password) is that it is mathematically impossible to obtain the original password from a hash (although it is theoretically possible to obtain a colliding hash input, the difficulty of which depends on the security strength of the hashing algorithm). The possible attack vector here is that if a potential attacker somehow compromised your password storage database, he/she still would not be able to obtain the original passwords of your users.
If your authentication mechanism sends a hash of the password, then in the "security breach" scenario (i.e. attacker somehow got a copy of your password database), the attacker does not need to know the real password - they just send the hashed password that they obtained from the breach and hey presto, they have access to that user's account. This completely defeats the point of storing a hashed password in the first place!
The really secure way to do it is to send the client a one-time public key for them to encrypt the password, then you decrypt and re-hash it on the server-side.
By the way, this kind of question will probably get more expert responses over on Security StackExchange.
You're likely OK not to worry about this - as Dirk mentions even if you hash the passwords a malicious user could be on a network and see the hash get sent, and could simply send the same hash themselves.
It is slightly better, in that it prevents the malicious user from knowing what the password is, but since they can still log in (or potentially reconstruct the original password), that's not that helpful.
In general, if you're concerned about the safety of your user's passwords and data (and you should be!), you'll want to use a secure SSL server. If this isn't a concern for you for whatever reason you might as well not bother with hashing; it's just security through obscurity.
Edit Aug 2014: Google is pushing more and more strongly for websites to switch to HTTPS everywhere, because securing the communication itself is the only way to prevent network sniffing attacks. Attempts at obfuscating the data transmitted will only hinder, not stop, a dedicated attacker, and can give developers a dangerous false sense of security.
Recently both GitHub and Twitter announced that passwords where stored in internal logs. I've had this happen inadvertently in bug reports and other logs that found their way into splunk etc. For twitter if Trump's password was in there log it could be a big deal for an admin to "see", for other sites probably not as big of a deal as the administrators wouldn't have much use for it. Regardless as admins we don't like seeing the passwords do we.
So the question is really if the hashing should happen client side for security, but how can we protect the password before it ultimately gets hashed and compared by the server side so it doesn't get logged somehow.
Encryption is not a bad idea because the developers at least have to jump through some hoops, and if you find that passwords got into logs you can just change the encryption key, destroy the original, and that data becomes useless. Better yet rotate the keys nightly and it could reduce the windows greatly.
You could also hash a hash in your user record. The leaked passwords would be hashed plain text passwords. The server would store a hashed version of the hash. Sure the hash becomes the password, but unless you've got a photographic memory you are not going to remember a 60 char bcyrpt. Salt with the username. If you could gather something about the user during the login process (while not exposing that the user record exists ) you can salt with that as well creating a more robust hash that couldn't be shared between sites. No man in the middle would be able to just cut and paste the captured hash between sites.
Combine with a cookie that doesn't get submitted back to the server and you might be onto something. On first request submit a cookie to the client with a key, then make sure that cookie doesn't make its way back to the login service so little chance of it being logged. Store the key in a session store, and then delete it right after login occurs or when session expired... this requires state for you JWT guys, but maybe just use a nosql service for it.
So down the road an admin comes across one of these hashed and encrypted passwords in splunk or a bug reporting tool. It should be useless to them as they can't find the encryption key anymore, and even if they did they then have to brute force a hash. In addition the end user didn't send anything plaintext along the line so any man in the middle at least has a harder time of it and you can't just hop to another site and login.
Note that keeping passwords secure against third parties parties is not all there is to it.
As soon as privacy is involved (and when ever is it not, these days?) you don't want to know the password. You can't abuse or leak what you don't have, so both you and your clients can sleep better if you never ever see their clear-text passwords.
Therefore, hashing/encrypting client-side makes sense.
It depends, you can use client side hashing, but server side salt will not be possible.
have a look at the link
Password encryption at client side
This idea of client side hashing is to protect the user, not your site. As mentioned many times already, plain text or hashed passwords both have access to your site equally. You don't get a security benefit.
But your users actual, plain text, password should only be known by them. Knowing what they chose as a password is information that can be used against them on other sites and systems. You are being a customer-focused site by protecting them from having their password choice discovered by your server devs or by third parties.
I've been doing a lot of work on this recently, IRL there are two issues with client side hash / symmetric encryption with really kill the idea:
1. You have to get the salt back to the server SOMEHOW...and to encrypt it client side you'd need a password...which defeats the purpose.
2. You expose your hashing implementation (not a HUGE deal as most sites use one of 3 or 4 hashing algos) which makes the attack easier (as just need to try one rather than n).
What I eventually went to was asymmetric encryption on the client using OpenPGP.js or similar...
This relies on an imported or client side generated key on the client and the server sending it's public key. Only the client's public key may be sent back to the server.
This protects against MIM attacks and is as secure as the device (I currently store client's private key by default in localStore, it's a demo).
The MAJOR advantage of this is that I never have to have users data stored / even in memory unencrypted on my server / data store (and my server's private key is physically separate)
The basis of this was to provide people a way to communicate securely where HTTPS was restricted (e.g., Iran / N. Korea atc...) and also just a fun experiment.
I'm FAR from the first to think of this, http://www.mailvelope.com/ uses this
If someone can see the data in and out on your connection then authentication will not save you.
Instead I would do the following for super secret stuff.
Passwords prehashed on client side before sent to server.
(Server stores another hashed and salted value of that hash sent from the browser).
So a middle man attack could allow them to send the same hashed value to login as them, but the users password would not be known. This would stop them trying other services with the same credentials to login elsewhere.
Users data is encrypted on the browser side too.
Ah, so a middle man attack would get the encrypted data, but would not be able to decrypt it without the actual password used to login. (users password stored in the DOM on the browser when they logged in).
So the real user would see the decrypted contents but the middle man could not.
This also means any NSA or other agency would not be able to request you/company/hosting provider to decrypt this data as it would be impossible for them to do so as well.
Some small examples of both of these methods are on my blog
http://glynrob.com/javascript/client-side-hashing-and-encryption/
Consider this:-
Client sends request to server "I have a password to validate".
Server sends client a one-time only random string. R$
Client embeds the user's password in this string (based on any (variable) rules you wish to apply).
Client sends the string to the server and if password OK, server logs user in.
Should server receive another login request using R$, user is logged out and the account is frozen pending investigation.
Obviously all other (normal) security precautions would be taken.
The method that I have come up with is to use SHA-256 with multiple rounds and a random salt...
salt = generate random salt
hash = sha256(password)
for (i = 0 to rounds)
hash = sha256(hash + salt)
This encrypts the password in such a way that only the user knows what the password is. Both salt and hash are stored in the database. I have also implemented this on the client side using a server generated random string.
server_data = {
algorithm,
rounds,
salt,
string
}
hash = hash(server_data.algorithm, password)
for (i = 0 to server_data.rounds)
hash = hash(server_data.algorithm, hash + salt)
hash = hash(server_data.algorithm, hash + server_data.string)
In crypto class, we were taught that the attacker can know the algorithm, salt, rounds, etc.... But in this case, the actual hashed password is never sent. The server knows what the random string that it sent was, so the full hash is generated on the client, and the final piece is to hash that result with the random string. That's the result that's sent to the server. The result is effectively a one-time password that is useless on replay attacks. The user's password is never sent in the clear, and if the attacker gained the password hash, it would be useless to them because the server will not accept it in that form. The hacker MAY be able to compute a rainbow table for the salt and the number of rounds to try and brute force the password, but any sufficintly complex password using ASCII symbols 32-126 of at least 8 characters long will usually take a long time to crack...and that's for EACH password. The sites that I write for can have passwords up to 128 characters in length.
As for session hijacking, that risk can be reasonably mitigated by regenerating the session ID every 30 seconds or so. I also include a token that's embedded in the HTML of the page itself. On the server side, some of the client information such as the client's IP address and user agent string are hashed as well and stored in the user's session data.
So on each request, the server gets the cookie session ID and the token. The token is compared to what is in the session data. The other information such as the IP address and user agent are hashed and compared to what's in the session as well. If it all matches, then there's a very high probability that this is the real user and not an intruder.
The only way that I can see this happening is if the attacker has the embedded token, the same IP address, and the same user agent. It's all about probabilities. Besides, any time you are dealing with crypto, it can be hard to get right. So as others have said, don't do it yourself.
It's 2022 now. As hacker attacks are getting more sophisticated, luckily also have browser standards. The defacto transmission protocol is encrypted (https) and cross site scripting or replay attacks systematically are more difficult with content security policies and CORS.
I believe your time will be well spend familiarising yourself with these technologies.
I'm not a security expert and leave that in the hands of more capable engineers.
I'm making a simple star rating feature in PHP to my site and my general question is, do cookies prevent people from spamming multiple votes?
As far as I know I can store a cookie with javascript and PHP. What's to prevent the spammer from testing the feature, looking at what cookies are saved and then remove/add them in the spam attack script?
A sub question would be, what should I save in the cookie? That the person has already voted? What's to prevent the spammer from automatically delete all cookies before a spam attack?
So far I've got honeypot, secret code calculated by time and some other things and IP blacklisting.
I will try to stay out of captchas and recaptchas.
Here's the fact: At the worst possible case, a user may get an entire new computer to cheat your system. And there's nothing you can do about it. So no matter which client-side protections you have, they can be broken.
Cookies are trivial to reset.
Sessions rely on cookies, hence, trivial to reset.
IP is easy enough to reset (or use a VPN or some other such service), moreover, mobile devices change IPs as you walk down the street.
The only real way is to authenticate your users (i.e. a login system) and only allow for authenticated users to vote.
Note that a Cookie will probably work for 95% of the cases, if you don't care the occasional cheat here and there. If cheating must be prevented at all costs, you need an authentication system.
Looks like you are talking about anonymous / unauthenticated users (guests) - because if it's logged in users you can validate on server-side much more easily (e.g with Zanderwar's answer on sessions).
I'm sure you already know this rule, but in case you don't know:
Don't do security validations on client side - you never know what browser, mobile or client the user is using. It's very easy to strip aside client side validations, spoof REST variables, encode/decode, replay transactions etc on the modern clients. So don't do security validations on clientside. Client side validation should only be used to enhance the user experience, and proper security validation should be done on server side only.
For unauthenticated, anonymous users I would restrict submissions by IP and time. E.g per IP they can only submit once per hour. You will have to record the IP and time on serverside and reject (or just update) submissions that are too frequent.
This is the simplest solution to your problem I can think of.
There is no way to prevent spam with cookies or sessions. Any time you spend on this concept will be entirely wasted.
That doesn't mean that the session control can not be useful but it can not by itself prevent an experienced user from anything.
Voting sites usually rely either on an authentication system or the client's IP and time stamp to limit users.
Using the browser string together with IP would make it harder but you run the risk of preventing multiple people behind the same firewall (same IP) from voting if they have very similar setup (as you could have in an office)
Aside from that login is another option but could be circumvented by creating multiple accounts.
But preventing multiple votes is always a problem unless you have an existing verified identity of the visitor.
It will never get a full protection without using Captcha or any other anti-bot protection as long as you give guests to use this feature.
The closest you can do, is to block by User-Agent + IP if they vote to much in a certain amount of time.
Another thing, you can do is to find a workaround using JWT authentication. It's a nice tool for client side session management.
Also, you can try and implement a CSRF protection. For example, you can create a unique token when loading the page of the vote, and when a user clicks on one of the stars, the system will send this token along with the vote rating.
But, again, there is no a bulletproof solution for your problem.
I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.
I have a quetion which may be simple/dumb or not :). In other words I have no idea if is fair enough or a completely foolish idea. Just some free thoughts.
What if I make my login via JavaScript with pass in it (yes I know), but pass will be hased by Secure Hash Algorithm. For instance:
I generate a pass with SHA which looks like
var = 0xc1059ed8... //etc
and paste into the code. There will be also two functions. One will compare two values (given by me with user's) and second will generate sha form user's input.
Is this could be safe theoritically or this is a horrible pattern and stupid idea? Can JS handle it?
EDIT: I didn't mean serious autentication like banking one. Just when I have my pics and want only to a few ppl to watch them and 99,9% of ppl on earth can't watch them :)
thx for responses
Sorry, no dice :) Secure authentication is not possible with client-side Javascript alone, because a positive authentication result could be faked. You will always need a server-side instance to authenticate against.
The common answer is that 'no, you can't do client side authentication' and for conventional scenarios that is correct, but I can think of at least two ways to make it work:
Use the SHA password hash to redirect to a static HTML page (0xc1059ed8...html). As long as the virtual directory doesn't allow file listing, no one will be able to guess the name of the file you want to protect. This gets clumsy really fast though.
Use an implementation of an encryption algorithm (AES, etc) in Javascript to decrypt a block of text that makes up the actual content of your page. Really only practical for one highly valuable page though.
Server side authentication is really the best, but it is incorrect to say that client side can't be done.
You cannot secure your site with Javascript alone. You will need some way to authenticate requests on the server.
Because all your javascript code is plainly visible to all consumers of your site. All a potential attacker would need to do is view souce of your website and they can bypass the password checking bit of your javascript and view the content behind it.
You need to have security implemented on the server-side, period the end. ASP.NET has a built-in way to do this called "Forms Authentication." Or you could use Session variables in a php script.
Your JS source will be visible anyway and anyone can fake it easily. You have to do a server side validation
Since the hash will reside on the user's computer (in the browser), i'd say it's a terrible idea. It will be easy to manipulate it.
You can use such a pattern to hide the password over a plaintext link and avoid https to login , but not as it stands.
The problem is that an attacker can steal the hashed password and use that to login to the server, and she does not need the real password.
This can be thwarted by a challenge response where the server sends with the page a "salt" : a big random number which is jumbled up with the password and then hashed, so the response is always different.
Unfortunately this has the effect that the server now needs to have plaintext passwords, which is a bad idea (ok, there are some tricks around this). So you might have to end up with a sending a salt, hashing your password, jumbling the hash with the salt by hashing it again and sending that to the server. The server hashes the stored hash of the password from the user db with the salt and compares both.
With security things get complicated real quickly and in complicated things opportunities lurk for the bad guys. A reason more to use well tested patterns, algorithms with a proven track record and libraries which have carefully implemented these.
And in any case it will be the server hwo has final say who can get access.
You'd be better off with no attempt at authentication at all -- at least that way you wouldn't give anybody the dangerous illusion that something involved might be secure.
Assuming you're dealing with a shared-secret situation, authentication is really pretty easy. You use a fairly simple challenge-response algorithm. Basically, the client sends a message to the server saying it wants to log in. The server responds by sending back a random number. The client encrypts that random number with the correct password, and sends it back. The server encrypts the random number itself, and compares the result to what the client sent. If they match, authentication has succeeded -- you've confirmed that the client has the right password.
The advantages of this: first, the password itself is never sent over the wire in any form, so an attacker has virtually no material to use in attempting to discover the password. Second, since the server generates a new random number for every login, an attacker cannot successfully authenticate by re-sending the packets it captured from a previous login.
Nearly any server with any sort of aspirations to security will already have something like this built in. It's purely a question of setting up your client to interact correctly with the form supported by the server(s) you care about.
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?
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.
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:
Has no server-side components (this tool and its password-protected pages run entirely in javascript).
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.
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.
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.
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
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.
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.
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. e.g rot13
You will need a JavaScript hashing script
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.
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!