By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,874 Members | 1,028 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,874 IT Pros & Developers. It's quick & easy.

JS password script

P: n/a
Max
Hello all,

I am trying to protect a page within my site with a JS password
scheme.
Now I know JS can be quite easily "circumvented", but I came by a code
below.

My question is:
1. Is there a way to find a password for this script? How easily?
2. Is there a stronger scheme available in JS?
<SCRIPT>
var texts = "5d4v129v3387ff76";
var interpret = "";
var whatisthis = "var xorm = prompt('Enter the password:','');for
(x=1; x<6; x++) {interpret += (texts.indexOf(x));}if
(xorm==interpret){interpret = interpret +
'.php';location.href=interpret;}else{location.href ='login.php';}";

eval(whatisthis);
</SCRIPT>
I thank you all.

m.
Jul 20 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Max wrote:
Hello all,

I am trying to protect a page within my site with a JS password
scheme.
Now I know JS can be quite easily "circumvented", but I came by a code
below.

My question is:
1. Is there a way to find a password for this script? How easily?
2. Is there a stronger scheme available in JS?
<SCRIPT>
var texts = "5d4v129v3387ff76";
var interpret = "";
var whatisthis = "var xorm = prompt('Enter the password:','');for
(x=1; x<6; x++) {interpret += (texts.indexOf(x));}if
(xorm==interpret){interpret = interpret +
'.php';location.href=interpret;}else{location.href ='login.php';}";

eval(whatisthis);
</SCRIPT>
I thank you all.

m.

This is a often asked question. You CAN protect a page securely with
javascript, but the effort is prohibitive.

Use an algorithm to encrypt the page. Write your own or there are, for
example, standard algorithms in javascript like triple DES. Use the
password entered to decrypt the page.

Since the password doesn't exist on the page, the page is secure as the
algorithm chosen.

However, maintaining such a page is very difficult. You will do MUCH
better using a server side solution.

Besides the above, some of your clients will have javascript turned off.
They will be unable to enter your site.

Jul 20 '05 #2

P: n/a
In article <pt********************************@4ax.com>, Max <no*****@all.ws>
writes:
Hello all,

I am trying to protect a page within my site with a JS password
scheme.
Now I know JS can be quite easily "circumvented", but I came by a code
below.
Bad code at that.
My question is:
1. Is there a way to find a password for this script? How easily?
See below.
2. Is there a stronger scheme available in JS?
Yes, and it is just as easily circumvented.
<SCRIPT>
var texts = "5d4v129v3387ff76";
var interpret = "";
var whatisthis = "var xorm = prompt('Enter the password:','');for
(x=1; x<6; x++) {interpret += (texts.indexOf(x));}if
(xorm==interpret){interpret = interpret +
'.php';location.href=interpret;}else{location.hre f='login.php';}";

eval(whatisthis);
</SCRIPT>


Lets re-write it, without the eval:

var texts = "5d4v129v3387ff76";
var interpret = "";
var xorm = prompt('Enter the password:','');
for (x=1; x<6; x++)
{interpret += (texts.indexOf(x));}

if(xorm==interpret)
{interpret = interpret + '.php';location.href=interpret;}
else
{location.href='login.php';}";
Now, lets have the script itself tell us what interpet holds:

var texts = "5d4v129v3387ff76";
var interpret = "";
var xorm = prompt('Enter the password:','');
for (x=1; x<6; x++)
{interpret += (texts.indexOf(x));}
alert(interpret)
//Gives me 45820

if (xorm==interpret)
{
alert('You got it right')
//interpret = interpret + '.php';location.href=interpret;
}
else
{
alert('You Got it Wrong')
//location.href='login.php';
};
Entering 45820 alerts me that I got it right.

Time to get it: less than 60 seconds.
--
Randy
Jul 20 '05 #3

P: n/a
Hi,
I am trying to protect a page within my site with a JS password
scheme.
Now I know JS can be quite easily "circumvented", but I came by a code
below.
The password to the code you posted is "45820". If you enter this password, you will be redirected to the page
"45820.php" (current server), if you enter any other string you will be redirected to the "login.php" page.

For obtaining the password from the posted code, this chunk can be used:

var texts = "5d4v129v3387ff76";
var interpret = "";
for(x=1; x<6; x++) {interpret += (texts.indexOf(x));}
alert(interpret);

(This circumvents the burden of manually counting the positions of the numbers 1..6 in the obscure "texts"
string :) )
My question is:
1. Is there a way to find a password for this script? How easily? Let me answer it this way: You posted your message at 23:40, I read it approximately 23:55, it is now 0:21.
Moreover, there is one colleague who answered it way more quickly than me.
2. Is there a stronger scheme available in JS?

You could try the following: Don't make the decision "is that the correct password" in the Javascript, since
this will require that you have either (1) the password stored in your script as a plain string (which is
ridiculous) or (2) the password stored in some obfuscated way plus a mechanism your script uses for
de-obfuscating it (which is trivial to crack: just insert an alert(...) after the no-matter-how-complicated
decryption routine. HikksNotAtHome an I did it that way since we were too lazy to figure it out manually).
Either way, you are delivering everything needed for cracking your protection bundled with the page.

The only possibility I can think of is this: Leave the decision "is that password correct" to the server,
since then you don't have to have the password stored client-side (i.e. in your Javascript). Just redirect to
the string the user entered: if it is the valid "password" string, then the page will appear, if not so, the
server will send you a 404 (file not found). Unless your server allows directory content listing, this should
be somewhat more secure than the above idea.
Don't get me wrong: no matter from which angle you look at it, all this is pretty much a poor man's password
protection. The second method, for example, suffers from anyone knowing the url instantly having access, which
means: a quick glance at the browser cache of a machine that accessed the 'protected' page, or at the proxy
logs somewhere along the way towards the server, will break your protection. But it's better than nothing.

For any decent password protection, you'll (imho) definitely need a server-side solution; consider PHP or Perl.

Best regards
Hendrik Krauss

Jul 20 '05 #4

P: n/a
Max
hi************@aol.com (HikksNotAtHome) wrote:
Bad code at that.
Yes, I know. I just copy-pasted as I found it...
Now, lets have the script itself tell us what interpet holds:

var texts = "5d4v129v3387ff76";
var interpret = "";
var xorm = prompt('Enter the password:','');
for (x=1; x<6; x++)
{interpret += (texts.indexOf(x));}
alert(interpret)
//Gives me 45820

if (xorm==interpret)
{
alert('You got it right')
//interpret = interpret + '.php';location.href=interpret;
}
else
{
alert('You Got it Wrong')
//location.href='login.php';
}; Entering 45820 alerts me that I got it right. Time to get it: less than 60 seconds.


1 minute?!
<deep sigh>
No good way of protecting a page, it seems.

Anyway, tnx!

m.
Jul 20 '05 #5

P: n/a
Max
Hendrik Krauss <us****@removethis.hendrik-krauss.andthat.de> wrote:

<snip>
For obtaining the password from the posted code, this chunk can be used:

var texts = "5d4v129v3387ff76";
var interpret = "";
for(x=1; x<6; x++) {interpret += (texts.indexOf(x));}
alert(interpret);

(This circumvents the burden of manually counting the positions of the numbers 1..6 in the obscure "texts"
string :) )
LOL
I tried it myself just now.
What an easy way to get through...
Oh well...
My question is:
1. Is there a way to find a password for this script? How easily?

Let me answer it this way: You posted your message at 23:40, I read it approximately 23:55, it is now 0:21.
Moreover, there is one colleague who answered it way more quickly than me.


I see your point.
;-(
2. Is there a stronger scheme available in JS?

You could try the following: Don't make the decision "is that the correct password" in the Javascript, since
this will require that you have either (1) the password stored in your script as a plain string (which is
ridiculous) or (2) the password stored in some obfuscated way plus a mechanism your script uses for
de-obfuscating it (which is trivial to crack: just insert an alert(...) after the no-matter-how-complicated
decryption routine. HikksNotAtHome an I did it that way since we were too lazy to figure it out manually).
Either way, you are delivering everything needed for cracking your protection bundled with the page.


Aha.
I understand.
So, basically, every visitor with some insight into JS coding will be
having a good laughter at my expense...
Not good.
The only possibility I can think of is this: Leave the decision "is that password correct" to the server,
since then you don't have to have the password stored client-side (i.e. in your Javascript). Just redirect to
the string the user entered: if it is the valid "password" string, then the page will appear, if not so, the
server will send you a 404 (file not found). Unless your server allows directory content listing, this should
be somewhat more secure than the above idea.
Something like code below?
Don't get me wrong: no matter from which angle you look at it, all this is pretty much a poor man's password
protection. The second method, for example, suffers from anyone knowing the url instantly having access, which
means: a quick glance at the browser cache of a machine that accessed the 'protected' page, or at the proxy
logs somewhere along the way towards the server, will break your protection. But it's better than nothing.
I see.
Thank you for your explanations.
For any decent password protection, you'll (imho) definitely need a server-side solution; consider PHP or Perl.
Yes, I see that now.
PHP, here I come.
Best regards
Hendrik Krauss


I found this on one page, looked at source and copied it.
I don't write JS, as you can see.
:)

<SCRIPT language="JavaScript">

function gateKeeper() {
var password = prompt("Enter passwrd!", "")
var location=password + ".htm";
this.location.href = location;
}
</SCRIPT>

Tnx guys!!

max
Jul 20 '05 #6

P: n/a
In article <t3********************************@4ax.com>, Max <no*****@all.ws>
writes:

I found this on one page, looked at source and copied it.
I don't write JS, as you can see.
:)

<SCRIPT language="JavaScript">

function gateKeeper() {
var password = prompt("Enter passwrd!", "")
var location=password + ".htm";
this.location.href = location;
}
</SCRIPT>

Tnx guys!!

max


Whats the point in asking me for a filename when if I know the filename, I can
simply navigate to the file itself? But, in your previous post, it used .php as
the extension, and if you have PHP available, its a lot more secure than JS is.
And yes, 1 minute. Long enough to copy/paste to a test page, add the alerts,
comment what I didn't want, and testing it.
--
Randy
Jul 20 '05 #7

P: n/a
On Sun, 05 Oct 2003 23:40:11 +0200, Max <no*****@all.ws> wrote:
Hello all,

I am trying to protect a page within my site with a JS password
scheme.
Now I know JS can be quite easily "circumvented", but I came by a code
below.

My question is:
1. Is there a way to find a password for this script? How easily?
2. Is there a stronger scheme available in JS?
<SCRIPT>
var texts = "5d4v129v3387ff76";
var interpret = "";
var whatisthis = "var xorm = prompt('Enter the password:','');for
(x=1; x<6; x++) {interpret += (texts.indexOf(x));}if
(xorm==interpret){interpret = interpret +
'.php';location.href=interpret;}else{location.hre f='login.php';}";

eval(whatisthis);
</SCRIPT>
I thank you all.

As others have indicated, this is not secure.

There are js "Secure Hash Algorithms" available (some for free if you
look). This then encrypts the password in a non reversable (well not
computationally feasible) manner and the result is compared, not the
password.

If the password is (after validating) then used as a redirect pointer
to another page, this is another weakness. For a secure method, use a
robust encryption (there are plenty and again some free js ones such
as DES3 etc) and use javascript to document.write() to innerHTML to
generate the protected page HTML at run time.

It is quite straightforward and not at all onerous.
Jul 20 '05 #8

P: n/a
"Chris Wright" <us****@holmwood.x.demon.co.uk> wrote in message
news:v5********************************@4ax.com...
On Sun, 05 Oct 2003 23:40:11 +0200, Max <no*****@all.ws> wrote:
I am trying to protect a page within my site with a
JS password scheme.
Now I know JS can be quite easily "circumvented", but I
came by a code below.

My question is:
1. Is there a way to find a password for this script? How easily?
2. Is there a stronger scheme available in JS? <snip>I thank you all.
As others have indicated, this is not secure.

There are js "Secure Hash Algorithms" available (some for free
if you look). This then encrypts the password in a non reversable
(well not computationally feasible) manner and the result is
compared, not the password.

<snip>

I don't see this as necessarily helping. Instead of having the password
in the source code of the page you would have the value of the hashed
password, and that would make getting back to the original password
(very) difficult, but if the hashed value is on the page, and the
comparison is done on the page, the user can re-define values and
functions so that either the function that hashes the entered password
just returns the value of the hashed password (so the comparison will
produce a true result), or short-circuit the comparison process and get
on with having the page de-coded and displayed.

This assumes that the entire process is client-side. If the unhashed
password is going to be sent off to the server for additional processing
then there is probably no point in validating it on the page anyway (and
downloading the hashing code to do so).

The approach that seems to work client-side (and obviously subject to
JavaScript availability) is where the password is the key to the
encrypted contents. The password is never validated as such, it is just
that only the real password will decode the data into the real HTML.
Even then this is not as secure as it seems at first as quite a lot is
known about the output of the decoding process, that is, it will be
producing HTML (and HTML contains predictable character sequences, even
in predictable locations sometimes). That means that the decoding of the
data without the password, while still difficult, is not as difficult as
it would have been if the output was just any arbitrary text (in any
language or even itself coded).

Richard.
Jul 20 '05 #9

P: n/a
On Fri, 10 Oct 2003 00:43:07 +0100, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

There are js "Secure Hash Algorithms" available (some for free
if you look). This then encrypts the password in a non reversable
(well not computationally feasible) manner and the result is
compared, not the password.

<snip>

I don't see this as necessarily helping. Instead of having the password
in the source code of the page you would have the value of the hashed
password, and that would make getting back to the original password
(very) difficult, but if the hashed value is on the page, and the
comparison is done on the page, the user can re-define values and
functions so that either the function that hashes the entered password
just returns the value of the hashed password (so the comparison will
produce a true result), or short-circuit the comparison process and get
on with having the page de-coded and displayed.

This assumes that the entire process is client-side. If the unhashed
password is going to be sent off to the server for additional processing
then there is probably no point in validating it on the page anyway (and
downloading the hashing code to do so).

The approach that seems to work client-side (and obviously subject to
JavaScript availability) is where the password is the key to the
encrypted contents. The password is never validated as such, it is just
that only the real password will decode the data into the real HTML.
Even then this is not as secure as it seems at first as quite a lot is
known about the output of the decoding process, that is, it will be
producing HTML (and HTML contains predictable character sequences, even
in predictable locations sometimes). That means that the decoding of the
data without the password, while still difficult, is not as difficult as
it would have been if the output was just any arbitrary text (in any
language or even itself coded).


It would be normal to validate the password (with SHA) and then use
the (undisclosed) password as you suggest to decrypyt. The validation
stage could be left out, but it provides an opportunity to manage
failed passwords more elegantly (with limited attempts, failed page
handling and maybe cookie blacklist - a variant on remember me!).

Modern encryption systems are not mere encoders, but encryption, using
random number generators and the partial encrypted code as as part of
the encryption key; mulitple passes etc. The cyphertext is not
practical without deploying (very) significant resoutrces.

I agree that server side solutions will give more protection, but if
only client side options are available, then they are reasonalbly
straightforward and viable with JavaScript.
Jul 20 '05 #10

P: n/a
On Fri, 10 Oct 2003 08:34:20 +0100, Chris Wright
<us****@holmwood.x.demon.co.uk> wrote:

I agree that server side solutions will give more protection, but if
only client side options are available, then they are reasonalbly
straightforward and viable with JavaScript.


Client-side password solutions are not viable, they are either utterly
insecure or incredibly slow, and entail the user entering the password
on every navigation.

If you think otherwise demo!

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.