I'm having trouble figuring out the problem with the following script. Adobe Dreamweaver says it has no syntax errors. I think it has to do with the variable types
var rand = new string("0");
rand =Math.floor(Math.random()*110000);
var len = rand.length;
var strings = new Array();
strings[1]=rand.charAt(0)
strings[2]=rank.charAt(1)
strings[3]=rand.charAt(2)
strings[4]=rand.charAt(3)
strings[5]=rand.charAt(4)
strings[6]=rand.charAt(6)
var reorder = new string("sl");
reorder=(strings[1]+strings[2]+strings[3]+strings[5]+strings[6]);
var numValue = reorder * 1;
var tim = getHours();
var stepone = numValue * tim;
var steptwo = stepone / 16;
var stepthree = steptwo * stepone;
var stepfour = stepthree * numValue;
var password = (rand);
var x = prompt(stepfour);
if (x.toLowerCase() == password) {
alert("Come right in \n \n You've entered in the right password")
As Old Pedant said recently, "It may or may not come as a surprise to you, but NightmarishStalker (the much more descriptive name for DreamWeaver) produces about the worst and most out of date JavaScript code possible. Such as new String(). Nobody that I know of in this forum is really willing to tackle DrunkWhomper code. We all prefer to just toss it out and use *GOOD* code."
You have a number of errors including a spelling error (rank). charAt() can only work with string values, not numbers.
Code:
var rand = Math.floor(Math.random()*110000)+100000;
rand = rand.toString();
var len = rand.length;
var strings = [];
strings[1]=rand.charAt(0);
strings[2]=rand.charAt(1);
strings[3]=rand.charAt(2);
strings[4]=rand.charAt(3);
strings[5]=rand.charAt(4);
strings[6]=rand.charAt(5);
var reorder=(strings[1]+strings[2]+strings[3]+strings[5]+strings[6]);
alert (reorder);
But the whole thing is pointless and futile. Password scripts produced by client-side coding (Javscript) are usually hopelessly insecure.
There are far better approaches to this.
“There are two kinds of failures: those who thought and never did, and those who did and never thought.” - Dr. Laurence J. Peter quotes (American "hierarchiologist", Educator and Writer, 1919-1990)
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
I've furthered it and realized that a standalone javascript will not show alerts or prompts unless you have the correct library
I now am still working out the cinks but this is what i have so far
javascript:
var password = Math.floor(Math.random()*110000)+100000;
password = password.toString();
var len = password.length;
var strings = [];
strings[1]=password.charAt(0);
strings[2]=password.charAt(1);
strings[3]=password.charAt(2);
strings[4]=password.charAt(3);
strings[5]=password.charAt(4);
strings[6]=password.charAt(5);
var reorder=(strings[1]+strings[2]+strings[3]+strings[5]+strings[6]);
var d=new Date();
var numValue = reorder * 1;
var tim = d.getHours();
function popup(){
alert(tim);
};
var stepone = numValue * tim;
var steptwo = stepone / 16;
var stepthree = steptwo * stepone;
var stepfour = stepthree * numValue;
function pop(){
alert(stepfour);
};
var x = prompt(stepfour);
if (x.toLowerCase() == password) {
alert("Come right in \n \n You've entered in the right password")
What keeps the user from just using "View Source" in their browser to look at the
"right.html" and "wrong.html" page references and go there directly?
I was thinking, since I am making a standalone javascript file to put into the server and link to it with the html file listed after the javascript, that people would not be able to see the "right.html" file since it is in the standalone javascript file.
I was thinking, since I am making a standalone javascript file to put into the server and link to it with the html file listed after the javascript, that people would not be able to see the "right.html" file since it is in the standalone javascript file.
All someone has to do is view source, get the path to the .js file, enter that in the browser, and it will display all the JS code in plain text.
__________________ ^_^
If anyone knows of a website that can offer ColdFusion help that isn't controlled by neurotic, pedantic jerks* (stackoverflow.com), please PM me with a link.
* The neurotic, pedantic jerks are not the owners; just the people who are in control of the "popularity contest".
The only remotely secure way in Javascript of redirecting with a password is to name the file the same as the password.
Code:
ENTER THE PASSWORD <input type = "text" id = "pwd" onblur = "gothere()">
<script type = "text/javascript">
function gothere() {
var url = document.getElementById("pwd").value;
url = url + ".html";
window.location.href = url;
}
</script>
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
You can easily have the encrypted text and the JS decryption sitting right there and it does no good without the keyword/password.
It *IS* true, though, that you can't store both the encrypted text and the password on the JS page. Which is what I was trying to say before I got beaten up. <grin/>
Now... So what? What good does it do to be able to require the right password in order to show some encrypted text? I think at that point, you probably are back to Philip's argument: The only USEFUL thing to do with the decrypted text is to have it be a URL and so you then jump to that URL.
You *could* encrypt the entire HTML content of the page, but that seems like a wrongheaded concept. Difficult to maintain, to say the least.
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
You can easily have the encrypted text and the JS decryption sitting right there and it does no good without the keyword/password.
It *IS* true, though, that you can't store both the encrypted text and the password on the JS page. Which is what I was trying to say before I got beaten up. <grin/>
Now... So what? What good does it do to be able to require the right password in order to show some encrypted text? I think at that point, you probably are back to Philip's argument: The only USEFUL thing to do with the decrypted text is to have it be a URL and so you then jump to that URL.
You *could* encrypt the entire HTML content of the page, but that seems like a wrongheaded concept. Difficult to maintain, to say the least.
Could you apply phillip's way of doing it as the encryption for the js link.
something like
There is indeed seriously flawed code, and I don't really see what it is intended to achieve. How is it different from the code I gave you in Post #8?
You can guess that this topic (passwords) has been discussed here a zillion times, and you are unlikely to find a novel solution.
document.write() is in effect obsolete. document.write() statements must be run before the page finishes loading. Any document.write() statement that runs after the page finishes loading will create a new page and overwrite all of the content of the current page (including the Javascript which called it). So document.write() is at best really only useful to write the original content of your page. It cannot be used to update the content of your page after that page has loaded.
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
There is indeed seriously flawed code, and I don't really see what it is intended to achieve. How is it different from the code I gave you in Post #8?
You can guess that this topic (passwords) has been discussed here a zillion times, and you are unlikely to find a novel solution.
document.write() is in effect obsolete. document.write() statements must be run before the page finishes loading. Any document.write() statement that runs after the page finishes loading will create a new page and overwrite all of the content of the current page (including the Javascript which called it). So document.write() is at best really only useful to write the original content of your page. It cannot be used to update the content of your page after that page has loaded.
The idea was to "encrypt" the javascript link (what Old Pendant was discussing in the previous post) in the same way that you made a password for the redirection to another page by using the name as the password. Thank you for telling me that javascript cannot be used to update the content of your page after the page loaded.
It is possible to obfuscate the link but anyone with knowledge of Javascript will soon crack it. It is for you to decide how undesirable/damaging that might be. In general if money or its equivalent is involved people have a motivation to break the "code".
Code:
<script type = "text/javascript">
function URL() {
var obfuscatedURL = "c6~q$2%d6h4%$47~f3%8$6w9%e~2b7%~56$d2%d~6k7%f~6a$9%86m3%";
var x = unpoopify(obfuscatedURL);
var url = unescape(x);
alert (url); // home.html
}
function unpoopify(a) {
a = a.split("").reverse().join("");
a = a.replace(/[~$]/g,"");
a = a.replace(/(\%\d\D)/g, "%");
return (a);
}
</script>
Instead of obfuscatedURL, name the var something like googlead1234
But any competent Javascript coder will soon crack this.
Here is another script, harder to crack:-
Code:
<form>
<p>Enter The Password To View The Secret Page <input type="text" name="Pswd" size ="12" maxlength = "12" onBlur="OneWay(this)"></p>
<!-- The password is x (case insensitive) max 12 characters -->
</form>
<script type = "text/javascript">
function OneWay(S) {
var pageName;
var y = 2e50;
var x = '0.'+ parseInt(S.value,36); // 36 is the radix
for (var j=0; j<10; j++) { x = Math.tan(1+x+x*y%1)%1 }
pageName = ((x+1)/2).toString(36).substring(2);
pageName = pageName + '.html';
alert (pageName); // for testing
//pageName = "xvmrv5eoae0b.html"; // when password is "x"
//window.location.href = pageName; // uncomment for use
}
</script>
But this has no great advantage over the simple script I gave you before. All it does is convert a password into an obfuscated url. But you could use the password directly as the url.
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
Except, Philip, if the decryption requires the user to enter a password, then even WITH the decryption code staring you in the face it can be a huge project for somebody to "break" the encryption. Certainly not impossible, but it would take even a hacker with powerful tools minutes to hours to do so. And some of the better encryption algorithms that I was shown (forcefully...<grin/>) would possibly take days to crack. All you can do is guess at passwords, shove them into the decrypter, and see if you can find a pattern in what emerges so that you can make a better guess at the next try. If the output is, itself, not plain text, then even looking at what emerges doesn't help a lot.
I could write a pretty simple encrypter that I would bet would take you hours, at best, to crack.
NOW...Is it "safe"? Of course not! Is it safe enough for practical purposes? Yes.
But, then, so is your idea of simply using a weird URL safe enough for practical purposes. I really like that idea. It's enough to keep out nosy people, even if it won't keep out the determined hacker who will try millions (or more) of combinations. I absolutely agree with you that it's a simple and effective way.
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.