Password protection through JavaScript

Monday Mar 20th 2000 by Joe Burns

This is the first in a series of script tips meant to discuss and describe the concept of creating password protection through JavaScript.

How'z it goin'...

This is the first in a series of script tips meant to discuss and describe the concept of creating password protection through JavaScript. I have three scripts, each better or worse than the last depending on your point of view, to show you. Each uses a different method of password protection. You choose which one you think is best.

The three are:

  • Password in script - hide script
  • Password equal to page name
  • Password encrypted through arrays

All three are effective to a point. As with most password protection, the protection is only as good as the user's ability to not blab the password. Where JavaScript has taken a bad rap in all of this is that many people say that the password is in the script, that it's easy to look at the code, grab the password and get in.

The second script above simply does not include the password so that's out. The first and the third do, but I'll show you how to make it darn hard to grab it from the code...if you can get to the code at all.

Let's get started with the first one.


Here's the effect

The password is "peppermint" - without the quotes. Before you do it correctly, put in incorrect passwords, leave spaces blank, hit CANCEL, and try to look at the pages code. You'll see how I hid it.

Here's the code


How about that? I wrote that code for a fellow prof who wanted a basic password system. The system works pretty well but is still crackable if you know how. Did you try to get the password? Hard, wasn't it?

The reason it was difficult was the way the script was put together. None of the password elements ran before prompt or alert elements. That way it was impossible to get the page by itself without some type of JavaScript element taking the focus of the browser. The moment you'd click to lose one item - another would pop up.

Let's look at the code:

var getin = prompt("What is the password?","") 

We begin with a prompt that runs first in the script. Every time this page loads, this prompt pops up first. You simply haven't time to get to the view source menu item.

The variable "getin" is given the value of the text the user puts into the prompt box.

One more thing...notice there's no text set to go into the text box part of the prompt. That way I can set up an event to occur if the user simply clicks CANCEL without putting in any text.

if (getin=="peppermint")
alert('You got it! In you go...')

The first IF statement is set up to work if the password is correct. If "getin" is equal (==) to "peppermint" (the password), then an alert box pops up. The box is again to keep focus away from the page itself. Once you click to close the alert box, the location.href hierarchy statement is enacted and the browser changes the page.

But what if the user puts in the wrong password?

? else
if (getin=="null")
if (getin!="peppermint")

The wrong password brings on the wrath of the else statement. I have the else statement set to itself be another If statement.

If the user just clicks CANCEL, then the variable "getin" will be null. I have that response set to go to a page called "nope2.html" that tells the user to stop hitting CANCEL. (NOTE: this doesn't work on all browser versions - but all versions will get the next blip of code).

If "getin" is not null, then it has to have a value put in by the user. If it is anything but "peppermint" (!=) then the page nope.html pops up instructing the user to try again.

That's basically it. It's not a hard script and the password appears in the code but it's darn hard to get to. The script creates a vicious circle than can only be broken by putting in the correct password or closing the browser window.

Have you figured out how to get to the code yet? The easiest method is to close the browser and re-open it on the page that would send you to the password page. Then put your pointer on the link, right click and download the target page. Then you would have the code and the password.

Had you thought of that? If not - then your user may very well not have either. Maybe this password script is the one for you. If what you have to protect isn't of high-end importance, this could be the one.

Can a script be built that doesn't contain the password? Sure. Next week we'll start it.

Next Week: No Password in Script

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved