views:

281

answers:

2

How can a user, using one of the major modern browsers, know for sure that he is running my unmodified javascript code even over an untrusted network?

Here is some more info about my situation:

I have a web application that deals with private information. The login process is an implementation of a password-authenticated key agreement in JavaScript. Basically during login, a shared secret key is established between the client and the server. Once the user logs in all communication with the server is encrypted using the shared key. The system must be safe against ACTIVE man-in-the-middle attacks. Assuming that my implementation is correct and the user is smart enough not to fall victim to a phishing attack there remains just one large hole in the system: an attacker can tamper with my application as it is being downloaded and inject code that steals the password. Basically the entire system relies on the fact that the user can trust the code running on his machine. I want something similar to signed applets but I would prefer a pure javascript solution, if possible.

A: 

You could have an external Javascript file which takes an MD5 hash of your login JS, and sends an Ajax request to the server to verify that it is correct and up-to-date. Use basic security or encryption practices here - public/private keys or some other method to be sure that the response came from your server.

You can then confidently display to the user that the client-side scripts are verified, and allow the login script to proceed.

JoshJordan
I'm not sure I understand your solution but I think that would just shift the trust on the verifying script. The entire reason I wrote this system is to avoid SSL, both for performance and security reasons.
@Toni: There is a reason TLS/SSL is the industry standard for dealing with this specific problem. It provides very high security at a relatively low cost. Sure, there is a performance hit when using SSL, but it is not enough of a performance hit to justify rolling your own Javascript-based solution. Regardless of what Javascript solution you come up with, you are going to have a tough time preventing DNS spoofing from breaking the whole thing. With SSL, it just works.
William Brendel
If the industry standard is so secure how come there are so many security problems? I have studied the alternatives very carefully before going this route, even if TLS was more secure than my custom system, it lacks the control I need for my application. I appreciate your advice nonetheless.
@Toni: Can you list some of the security problems you're talking about? Most of the problems with SSL were the result of absurdly short key lengths, or browser security holes, none of which are problems with SSL itself. The underlying protocol is quite secure.
William Brendel
Check my reply to William Brendel
+3  A: 

Maybe I am misunderstanding your problem, but my first thought is to use SSL. It is designed to ensure that you're talking to the server you think you are, and that no one has modified the content midstream. You do not even have to trust the network in this case, because of the nature of SSL.

The good thing about this approach is that you can fairly easily drop it into your existing web application. In most cases, you can basically configure your HTTP server to use SSL, and change your http:// requests to https://.

William Brendel
One more note about DNS spoofing, because it is so commonly brought up when talking about SSL and man-in-the-middle attacks. Even if an attacker spoofed a DNS response and pointed your users to a malicious web server, the malicious server would still need the correct certificate on their end. When they fail to produce the correct certificate, the user's browser will throw up all sorts of red flags.
William Brendel
SSL has many weaknesses, mostly because it's complex, so my system is designed to replace ssl in my application (but it is not a replacement of ssl in general).
Many weaknesses? Can you elaborate?
William Brendel
The web is filled with examples. While I can't break SSL myself there are published papers about chosen plaintext attacks or known plaintext attacks, downgrade attacks and others. It may be safe "enough" for some applications but not for mine.The truth is that most (all?) weaknesses are implementation specific, but that is why I want my own implementation.I also need to authenticate the users using a password, I don't know of any browser providing support for decent password authentication schemes, and even if they had support for them I need to control the user interface too.
The fact is that SSL is "safe enough" for basically every major business on the web today. Every time you buy something online, you're using SSL. Every time you log into your web-based email, you're using SSL. Every time you check your bank account online, you're using SSL. If the companies in any of the above situations aren't using SSL, switch immediately.It sounds like you have your mind set on writing your own solution, so I'm not going to waste any more time convincing you that you're wrong (sorry to be so blunt). Eventually you'll learn it (the hard way) on your own. Good luck to you.
William Brendel