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