Passworded pages

[fawn]

I have a password JavaScript, and for the most part it does what I want. Here is the script:

<SCRIPT LANGUAGE="JavaScript">


var password = "heaven" ;
// The desired password

var message = "This is out of bounds,if you have the password come right in, if not please leave ";
// The message to show when the user is prompted for the password

var incmess = "Looks like you weren't invited, Please leave!";
// The message to show if the password is incorrect

var pw = prompt (message,"");

if (pw != password) {
alert (incmess);
window.history.back ();
}

</SCRIPT>


If the password is entered incorrectly, it goes back to the last page. What i would like to do is have it redirect to a page of my choice. How can I alter this script to accomplish this?

Any help is greatly appreciated.

[pyro]

Fitst of all, you do realize that anyone can gain access to the username/password by simply viewing the source, right? You'd be better of useing a server side language such as PHP, Perl, or ASP.

Anyway, you need to change this line:
window.history.back ();
to:
top.location.href = "somepage.htm";

[fawn]

Yes I realize that if someone gets to the base page they can get the password. I thank you very much for the help as it worked perfectly and does exactly what I want it to.

Thank you very much

[pyro]

You're welcome... :)

[Nevermore]

I know JavaScript password protection will never be 100% secure, but if you encrypted everything (username, password, destination page) and had them encrypt using a complicated algorithm, I should think you could get people to stop trying to get in. I might make one like that, and see how long it takes to break...

How long do you think?

[pyro]

I think encryption algorithims is best left to cryptologists. That is how the most secure algorithims are going to be made. For instance, MD5 produces a 128-bit "fingerprint" or "message digest" of the input. Odd's are, you won't come close to that using your own algorithm, so my question to you would be "why"?

[jeffmott]

I might make one like that, and see how long it takes to break1) Cryptologists can do a lot with what would otherwise appear to be garbage. It is really amazing what they can do sometimes.

2) It only takes one person to break it. If someone else wants in but can't do so themselves, they can always go to a forum and ask for help. Also, if the script is well known, decryption programs are easily found on the Web. A good example was Microsoft's JavaScript encrypter seen a while back (what was the name of that?). It was actually easier to find the program to break it than it was to find the encrypter.

3) Waiting to see how long your protection scheme holds up is a very bad way to measure security. If a malicious user found a hole in your security allowing them complete access, do you really think they would tell you?I know JavaScript password protection will never be 100% secureIn fact, JavaScript can be secure. Managing the users/passwords would be hell, but it could be done. However, no one ever seems to actually do it. I would guess the reason why is because those who could do it will always opt for server-side programming to handle the security instead.

[jeffmott]

However, no one ever seems to actually do it.Decided to give it a go. [Attached]

All criticisms welcomed. And I won't b!tch if I don't like the answer ;). I'm sure we know we get enough of that around here.

28 hours and counting :rolleyes:

[jeffmott]

whoops, forgot to do the whole attachment thing. errr, sleeeeep...........

[jeffmott]

Also note that server directory indexing MUST be disabled for this to be effective.

[Nevermore]

Originally posted by pyro
I think encryption algorithims is best left to cryptologists. That is how the most secure algorithims are going to be made. For instance, MD5 produces a 128-bit "fingerprint" or "message digest" of the input. Odd's are, you won't come close to that using your own algorithm, so my question to you would be "why"?
I got up to 64 bit encryption in conjunction with a security specialist - that would take a while to break. And yes, I know they broke 64 bit years ago. But in the same way that most people won't make 64 bit, most people can't break it either.

[jeffmott]

But in the same way that most people won't make 64 bit, most people can't break it either(This is all assuming you're making a hashing algorithm, since you never explicitly said.)

Most people don't make 64-bit algorithms because they are insecure, and this is your same reasoning for why people can't break it?!?

As I've already said, it only takes one person and your secret's out. When attempting the break the security of someone's script, the first thing I do is check to see if it has already been broken (and 95% of the time it has).

Also, there is far, far, FAR, (did I stress far?) more to creating a secure hashing algorithm than the size of its output. And, even if a birthday attack wouldn't be sufficient (though in your case it is), who's to say that there isn't a different attack that would find a collision quicker? I would assume you and your "security specialist" ( :rolleyes: ) have written out proofs showing how your algorithm is resistent to all known methods for attacking hashing algorithms?

[Nevermore]

We were only building it to see how secure a JavaScript encryptor can get without getting lagged and useless. Normally, you would never consider using anything under 96 bit encryption.

Incidently, my 'security specialist' works for the GECP and is leading the project to test new attack methods against 256 bit symmetric encryption. At present it is believed that 128 bit encryption, as used in PGP and in many government applications, may be vulnerable to new attack methods within the next 20 years. Obviously this is a terrible problem for global security, and world leaders need to know whether to switch to 256 and 196 bit encryption, or whether these are also compromisable and they have to switch to 'identibook' techniques, which at present are used for the most sensitive data as they are believed to be unbreakable, and their is no reason that any new technology will ever change this.

Hope this clears things up - I'm not advocating using low-power encryption for anything but 'messing about' with programming. :D

[jeffmott]

We were only building it to see how secure a JavaScript encryptor can get without getting lagged and useless.This is completely dependant on the algorithm used. Some algorithms are both more efficient and more secure than others. Your measurements would be for your algorithm alone. If you do plan on measuring its efficiency, you should show how the results compare to other algorithms.Normally, you would never consider using anything under 96 bit encryption.Actually 128-bit is considered the minimum. And in hashing algorithms, some cryptographers still have worries about 128 being too small. leading the project to test new attack methods against 256 bit symmetric encryptionWhat symmetric encryption? Attacks vary diversly from one algorithm to another. The only attack that would be common to all algorthms encrypted with the same key size is brute force. And brute force is a very simple method that can be calculated without the need for testing. At present it is believed that 128 bit encryption, as used in PGP and in many government applications, may be vulnerable to new attack methods within the next 20 years.Since you again refer only to the key size, I can only assume you are referring to a brute force attack. In which case the solution to strengthen the encryption is to increase the key size. Nothing new and nothing complicated. and world leaders need to know whether to switch to 256 and 196 bit encryptionI'm not sure what else may factor into this decision, but I would say why not? All my CGI programs use Rijndael with a 256-bit key.
*BTW, I think you mean 192, not 196; or whether these are also compromisable and they have to switch to 'identibook' techniquesI'm unfamiliar with the term, and Web searches turned up nothing. And I do mean nothing. Google had 2 results, MSN none, and AltaVista 1, and Usenet newsgroups has absolutely no mention of it.which at present are used for the most sensitive data as they are believed to be unbreakableMost corporate encryption schemes use 3DES. And goverment secured data use either 3DES or AES (or whatever the NSA has developed behind closed doors). And "identibook" still remains a mystery to all.and their is no reason that any new technology will ever change thisNo matter the encryption scheme, there is always the possibility that a new discovery (either in technology or mathematics) that would render the algorithm insecure.Hope this clears things upNo even close. There wasn't a single intelligent or informed point that was made.

[jeffmott]

my 'security specialist' works for the GECPBTW, what's the GECP that this specialist works at? The only searches turned up were mostly environmental organizations. Nothing dealing with technology or cryptography. Perhaps you could expand the acronym or provide a link.

[Nevermore]

Just to clarify: Identibook: A 'brand name'* style term for a code which uses a code based on random number sequences known to all recipients, but which cannot be predicted.

*i.e. Not the correct term, but the one that I have always been taught. Sort of stuck in my mind.


Actually 128-bit is considered the minimum. And in hashing algorithms, some cryptographers still have worries about 128 being too small.

Oh. I thought it was 96 bit. Things move on quickly, huh?

[Nevermore]

I should probably explain that I was not making a secure encrypting engine, I was playing around with making a JavaScript equivalent of the WW2 Enigma machine. It got a bit more powerful, thoug - I think I read somewhere that the enigma was less than 32 bit equivalent.

[jeffmott]

Just to clarify: Identibook: A 'brand name'* style term for a code which uses a code based on random number sequences known to all recipients, but which cannot be predicted.Possible you are referring to a one-time pad? Requirs a truly random (not psuedo-random) sequence that is the same length as the message for the key. Not very practical, but used on occasion for ulta-secure channels. The hotline between the United States and the former Soviet Union was rumored to be encrypted with a one-time pad. You were correct in your description. This is the only method of encryption that will remain secure no matter the amount of computing power. However, I still have never heard it referred to (nor any mention in all of Usenet) as "identibook". I'm a little curious from who/where you learned this.I was playing around with making a JavaScript equivalent of the WW2 Enigma machineIt would have caused less confusion if you had mentioned this earlier. Since the discussion centered around a practical application for security, your post was interpreted as such rather than an academic experiment.

[Nevermore]

Sorry - when I first typed out my first post I did include why I had built the script, but I lost the connection before I could post. (I was running off wireless at the time. Tunnel.). The second time round I couldn't really be bothered.