JS password script

[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.

 

[Jerry Park]

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.

 

[Hendrik Krauss]

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

 

[Max]

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.

 

[Max]

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...

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.
;-(

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

 

[Chris Wright]

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.

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.

 

[Richard Cornford]

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.

 

[Chris Wright]

<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.

 

[Jim Ley]

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.