views:

960

answers:

3

Sometimes HTTPS is not enough. Specially when we are talking about protecting user data from troyans with access at winsock32 level where they can sniff https in plain text or BHOs objects that already have access to the decrypted posted data in the browser memory.

In this scenario, I have developed a javascript -> classic asp client server routine, in wich the javascript encrypts and send the data received and decrypted by ASP. It works very fine.

This solution was built with xICE encryption wich offers a good compatibility between javascript and PHP or ASP. But now I'm migrating to ASP.NET or to Java and there's no port for these environments in XICE.

¿Any suggestion?

+2  A: 
erickson
+3  A: 

Fundementally, SSL is enough. Or rather, as good as you can get.

Anything that a client can see, via JavaScript or otherwise, can be seen by trojans and such on the client.

Any JavaScript encryption is security by obscurity.

Will
You need to see how a troyan can cath the post data in plain text and send it by IRC to a IRC server regardless of the SSL! SSL is not enough, believe me. The javascript encryption removes any plain text posted variable and prevents the data to be catched by sniffers over the winsock and BHOs (Browser Helper Objects). By the way BHOs can read directly from the Browser memory and they see the data all time in plain text.
backslash17
There are a couple of use cases for Javascript encryption. For one thing, Javascript can serve as a means to provide transparency rather than obscurity. Also, many frameworks scatter copies of sensitive information around during the course of request processing. Public-key encryption of fields like a credit card number right in the browser could be used to stop that. Or maybe users subscribe to private web-based data storage. You can read some rationale at http://www.fourmilab.ch/javascrypt/#why
erickson
I agree with Will on the client-side security. If the client box is compromised, there's no hope. Javascript seems most valuable when the user doesn't trust their privacy to the server, or the server is just one (untrusted) step in the chain to the ultimate destination.
erickson
Hey, I'm using SSL! But the javascript is to enforce the double encription to remove any text plain posted data! It seems that you have understand that I prefer javascript encryption over SSL. I'm just saying that SSL is not enough, not that i'm not using it. Of course I'm using it. Javascript encryption is just another additional security layer!This question causes the same reaction everywhere I posted it. I just want to know if there is any suggestion to use any other library.
backslash17
@backslash17 You're saying that since a trojan can deal with the SSL trivially you should add another layer. This is pretty pointless though since the trojan can deal with that one in just the same manner. Once bad guys own your computer it is *game over*. At best you are an inconvenience at worst your code puts the sensitive info into more places in memory making it more accessible.
ShuggyCoUk
The troyan sniffers works in a very specific way, they don't own your computer, they just sniff your http posted data! By the use of virtual keyboards and client side encryption (with server side generated key) you can reduce drastically the data capturing problems. This approach is working for more than 3 years with no criminal events at all.
backslash17
backslash17, thats snake oil.Pity the trojan authors who can't manage to see everything that happens on the box they 'own'.
Will
@Will: Do you have or not a suggestion about what I'm asking?
backslash17
Just use a caeser cipher.
Will
+1  A: 

Depending on the JavaScript library, it may be easy enough to port to C#, though you will probably want to run through and refactor it a bit. One of the best ways to learn a language is porting a library to it. Otherwise, there are plenty of implementations in JS for AES, and others. Many of these are optimized for ActionScript and JavaScript (some minor differences from EcmaScript proper).

Tracker1