Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 335
  • Last Modified:

Reverse engineering encrypted websites

This question may have nothing to do with security, but security is the term used by the developers I’ve been talking to. These developers are developing web services and a website based on the HTML5/JavaScript/CSS development model. They are concerned that people could reverse engineer their product since so much is in text. They know that encryption can be used to make it difficult to do this, but several hackers have been able to decipher supposedly encrypted websites. Is the concern about reverse engineering reasonable? Is there an effective way to encrypt such programs?
0
steve_webber
Asked:
steve_webber
  • 3
  • 3
2 Solutions
 
jrhelgesonCommented:
Nope.

In order for it to be viewed, it must be decrypted.

However, in a proper web application, all the coding is on the server that the client can never see, all that is displayed in the browser is the rendered content.  The back-end code is as secure as the web server platform is.
0
 
steve_webberAuthor Commented:
If the web page downloaded through a browser is HTML5 (not necessarily encrypted) and references a ".js" file, aren't these downloaded to the client site and therefore subject to discovery?
0
 
jrhelgesonCommented:
Yes, but that is only the client side they can see.  It is the server side that makes things secure.  The design should contain server-side components that are secured and validate all their inputs.  The server side obfuscates the client side components.  If a hacker examines the client-side, they will hack it and start feeding the server-side bogus data to get it to crash.

Security should be the top consideration insofar as design is concerned.  My biggest infosec lesson I learned back in ~2000; up to that point - every software that was ever built, or network ever designed was done to share information, not secure it.  Only after we built these things did we then think about security.  Don't make the same mistake.
0
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 
steve_webberAuthor Commented:
I guess the real concern of those I'm talking to is that someone can reverse engineer the secret sauce about how the web application works. It is not as much a concern about securing the data. I guess with Ajax and most of the real algorithms being on the server things are safer, but that means changing things a good deal to not send HTML and JavaScript to the client. Is this how you see it?
0
 
jrhelgesonCommented:
It's difficult to be precise without knowing your product, so I can only speak generally.
Therefore, generally speaking, the less you give to the client, the more control you will retain.

As a 'hacker' - I don't care two bits about your 'secret sauce' and nobody else does either. I'm interested on how I can use it against you, to manipulate it to get it to do something I want - which is usually something you don't want.

When it comes right down to it - there really isn't much of a way to stop people from figuring out how you're doing what you're doing.
0
 
Scott Fell, EE MVEDeveloperCommented:
The secret sauce should be on the server and that means your serverside code/api is doing all the work.   If you put your secret sauce in the js, there is nothing you can do to hide it.

As example.  Let's say your product is encryption and you want to demonstrate how you would use DES.  If you did this client side via javascript like the sample here https://code.google.com/p/crypto-js/#DES,_Triple_DES.  You can see below that your secret passphrase is in the javascript meaning anybody can see it.
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/tripledes.js"></script>
<script>
    var encrypted = CryptoJS.TripleDES.encrypt("Message", "Secret Passphrase");

    var decrypted = CryptoJS.TripleDES.decrypt(encrypted, "Secret Passphrase");
</script>

Open in new window

If you did this serverside where you posted a form to your server and did your encryption in your database or serverside code or even if you run your js serverside, your secret would not be seen.  I don't mean for this to be a discussion on the actual type of security here, just pointing out the difference.

I think what steve is talking about, "I don't care two bits about your 'secret sauce'" are the folks that may be scouring around your wordpress site for all the easy access you may have left open.  But you do have a valid concern. If I am your competitor, I may want to see how you do things.  There are a lot of lazy people that would rather "borrow" your method rather than being innovative on their own.
0
 
steve_webberAuthor Commented:
My concern about implementing "secret sauce" proprietary algorithms in JavaScript for a website to see was validated. The only solution seems to be to hide everything on servers. Even better, make sure any source is not on servers that are visible on the internet. Leave only compiled code on the visible servers.
0

Featured Post

Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now