[Newb-Man]

I Dare ANYONE to try to get passed this JAVASCRIPT ENCRYPTED website. I know, everyone keeps flaming JS Encryption [and are mostly right] but this can work NO PROB.

this is the website
BEWARE...it is not just hexadecimal encrypted [hexadecimal encryption sucks but at times fools a small majority].

[King Coder]

Who cares if the encryption works or not, it shows the password up in the URL... very unsafe.

[TwoD]

First, you do have a serious problem. It's called Brute-Forcing!

Second, the SSS has 15kb of extra JS code that needs to be downloaded. Yes, it could be compressed and it's cached, but it's still code that has nothing to do with the function of the site. That might be a small price to pay for the extra security though.

Your encryption/decryption algorithm works very well, as would any algorithm of that sort. Hey, if I really wanted to protect my site, I could write an RSA encryption/decryption algorithm, but it would still be just as vulnerable to the oldest trick in the book: patience.
Anyone clever enough to break "normal" obfuscation techniques could also write a brute-force-routine and simply wait for the password to expose itself by decrypting the site. Sure, it would take time, but what's inside is probably worth it if somebody put a big padlock on it.
Once the code has been decrypted with the correct key, it's easily accessible via the DOM.
What differs your algorithm from the other ways of hiding source is that it's using a real encryption algorithm (it depends on a key to generate the cipher-text), while the other methods rely on obfuscation or encoding, which either uses no key, or has the key stored with the cipher-text.

I personally think encrypting/obfuscating/encoding clientside code is pretty pointless. What's so important on a site that you'd need to hide the sources? Site layouts and design features can be ripped/recreated simply by looking at the pages. Script functionality can also be recreated, even if it takes a while longer than copying/pasting the original code.

Usually, people try to hide code on public pages that don't require any type of logging in. If you only allow certain people to visit your secure pages, I hope you trust them not to rip your code since you trust them not to make the password public. (Which also would mean you need to re-encrypt all your encrypted pages!)

I know you already know this, I'm just stating it "for the record"

[Newb-Man]

by the way this is not my code, the credits are on the page

[just for the record]

[TwoD]

hehe, I calculated that it would take me 2 million years to brute-force an 8 character long encryption key. (Assuming the characters A-Za-z0-9_ are allowed)
That's with my own brute-forcer made in JS, capable of testing a whopping 4 passwords a second (when running locally).

[jaxz]

How do I best use Obfuscation to "prevent"/slow down code-jacking of my javascripts?
What tools are useful for this?

And, the corollary, what tools do sneaky web masters use to decrypt such protected code?

Thanks,
Jaxz

[TwoD]

Jaxz, check the sticky thread in the JavaScript section.

It's not possible to decrypt the code since it is encoded using a hash, which is a one-way encryption method, unless you try every possible passphrase combination.¨

It is however overkill to do this kind of encryption and it's really a false sense of security.

To be able to use this particular method, you must hand out a password to each user who is allowed to view the site. Each time something changes on the site, it must be reencrypted with that exact password allow visitors to see updates.

But once a legitimate visitor has the password, he/she can also access the complete source code and rip it all anyway, just like if you had password protected the folder in which the sensitive files are. With the password, one can still copy everything so you'd have to keep a very close eye on who you let in.

If you don't want your scripts to be stolen, don't put them online. As soon as the script is downloaded to the client for excecution, he's got the whole source, no matter if you encrypted it or not.

[<?Wille?>]

Originally Posted by TwoD

hehe, I calculated that it would take me 2 million years to brute-force an 8 character long encryption key. (Assuming the characters A-Za-z0-9_ are allowed)
That's with my own brute-forcer made in JS, capable of testing a whopping 4 passwords a second (when running locally).

I was bored and reading some old threads, found this.
Was able to make my JS generate about 25000 strings per second, starting from aaaaaaaa to ________.
tested with 100 000 possibilities, stopped at aaaaaB3v which took 3959ms.
still it would take about 263½ years to go trough all 191 707 312 997 281 possibilities

[Vicious]

That's great, but please don't bump old threads

[TwoD]

If I remember correctly, generating the strings wasn't the big time eater, actually testing the generated passwords was.

Oh, and what Vicious said