Source Encrypter w/ Password protection?

[RottNKorpse]

is there a way or someone here who could add a password script that forces people to have a password in order to decrypt your encrypted source? Because otherwise they can just copy your source, then paste and decrypt it so kinda defeats the purpose of encrypting.

Here is the encrypt that I think should have a password thing added to it.
http://dynamicdrive.com/dynamicindex9/encrypter.htm

[Twey]

Oh-kay. Let's see.
Encrypting your code is:
a) pointless
b) selfish
c) impossible to do securely.

Pointless because you never really need to encrypt your scripts except for security reasons (password, &c.) which shouldn't be done client-side anyway;
Selfish because it restricts the freedom of the source, the thing that made HTML so popular in the first place;
Impossible because if the browser can understand it, it's already been decrypted at some point along the way, so the user can just ask the browser to tell what it sees:

javascript:alert(document.body.innerHTML);

in the address bar.

[RottNKorpse]

Encrypting your code is:
a) pointless (in a sense but it does stop the idiots that dont know what they are doing which basically is the point. The people that do know most dont care to steal.)
b) selfish (why should people get your source if you code it? they have the right to have it? lol um no, only if you want or dont mind them to. Some dont want it 100% public.)
c) impossible to do securely. (true but only wanting to stop the n00b thieves.)

[joshrodgers]

Wouldn't it be easier to create the page in asp and have a bunch of includes? That would get rid of most people. I mean if you are so concerned about security. That would not get rid of everyone, but it would get rid of the beginners (as you mentioned). If you stick with HTML you can make your code very far down the page (the source that is), because that throws beginners too. However, as Twey mentioned it is impossible to fully protect your source code.

[Twey]

Wouldn't it be easier to create the page in asp and have a bunch of includes? That would get rid of most people.

Erm... no. If you wrote it in a server-side language, it would appear in plain HTML to the user.

a) pointless (in a sense but it does stop the idiots that dont know what they are doing which basically is the point. The people that do know most dont care to steal.)

Untrue. No-one is likely to use your code intact. Anyone stealing your code must know enough to adapt it, so will know enough to crack your encryption.

b) selfish (why should people get your source if you code it? they have the right to have it? lol um no, only if you want or dont mind them to. Some dont want it 100% public.)

That's ridiculous. That's like writing an essay then refusing to give it to anyone, because they'll steal it. When you write code for the web, for anything in fact (although certain large corporations haven't quite grasped this yet), you're not writing it for yourself, you're writing it for the people who read it. There are other advantages to leaving the source open as well, such as the fact that people can spot bugs in your code and report them accurately. The only reason you should need to conceal your code is if it would be a security risk, such as if the password was contained in it. If this is the case, it should be done server-side.

c) impossible to do securely. (true but only wanting to stop the n00b thieves.)

Fair enough, but again, no reason to do so.

[joshrodgers]

lol. Sorry, was mistaken. I code mostly in asp which the client never sees (depending on how its written). Yes, they will see the HTML -- not sure what I was thinking. Anyway, thanks for the correction. Wouldn't want to give out misleading information.

[RottNKorpse]

well its not techincally for me..I run a resource site for a online gaming thing and the operators of the smaller sites are mainly all paranoid so just wanted to see if it was possible to get this done...no biggie, thanks for your replies.

[Twey]

Lol, tell them that there's no security risk in someone seeing your source - unless you're stupid enough to write a client-side password script.

thanks for the correction.

You're welcome