JS password script

Discussion in 'Javascript' started by Max, Oct 5, 2003.

  1. Max

    Max Guest

    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.
     
    Max, Oct 5, 2003
    #1
    1. Advertising

  2. Max

    Jerry Park Guest

    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.
     
    Jerry Park, Oct 5, 2003
    #2
    1. Advertising

  3. 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
     
    Hendrik Krauss, Oct 5, 2003
    #3
  4. Max

    Max Guest

    (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.
     
    Max, Oct 6, 2003
    #4
  5. Max

    Max Guest

    Hendrik Krauss <-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
     
    Max, Oct 6, 2003
    #5
  6. Max

    Chris Wright Guest

    On Sun, 05 Oct 2003 23:40:11 +0200, 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.

    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.
     
    Chris Wright, Oct 9, 2003
    #6
  7. "Chris Wright" <> wrote in message
    news:...
    > On Sun, 05 Oct 2003 23:40:11 +0200, Max <> 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.
     
    Richard Cornford, Oct 10, 2003
    #7
  8. Max

    Chris Wright Guest

    On Fri, 10 Oct 2003 00:43:07 +0100, "Richard Cornford"
    <> 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.
     
    Chris Wright, Oct 10, 2003
    #8
  9. Max

    Jim Ley Guest

    On Fri, 10 Oct 2003 08:34:20 +0100, Chris Wright
    <> 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/
     
    Jim Ley, Oct 10, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page