Is there a way to verify the integrity of javascript files at the client?

I'm working on what aims to be a secure method of user registration and authentication using php and javascript but not ssl/tls.

I realise this may well be considered an impossible task that's b开发者_开发技巧een tried 1000 times before but I'm going to give it a go anyway. Every example I see online that claims to do it seems to have some huge fatal flaw!

Anyway, my current problem is verifying javascript at the client. The problem being that if my sha1 implementation in javascript is modified by some man-in-the-middle it's not secure at all. If I could just verify that the received javascript has not been tampered with then I think I can pull this off.

The real problem though, is that the only way to do things on the client side is javascript. Simple: write a javascript to verify the integrity of the other javascript files. Nope! Man-in-the-middle can just modify this file too.

Is there a way around this?

To secure your JavaScript, you must examine it in an guaranteed untampered environment. Since you can't create such an environment in the browser this is not possible. Your best option is to download the JavaScript via HTTPS. That isn't safe but better. Possible attack vectors left:

• A virus can modify the browser to load some malicious JavaScript for every page
• A keylogger can monitor what the user is typing
• A proxy can act as a man-in-the-middle for an HTTPS connection. The proxy will actually decode what you send via HTTPS and encode it again (with a different certificate) for the browser.
• A proxy can add iframes to the pages you send

Matt I believe (despite the naysayers) that what you're asking is not impossible, merely extremely difficult. What you're asking is that code that is completely accessible to abuse nevertheless permits the user to identify herself to the server, and vice versa. One possible way is to use a zero-knowledge proof, which will leak no information to the eavesdropper (Eve). For example, the server might provide javascript that draws a representation of a graph that combines user provided information of no value to Eve on its own with server-provided information also of no value. The javascript may have been modified, but will either fail to provide the correct graph (at which point the user WALKS AWAY) or succeed. In the latter case, the user similarly provides 'zero-knowledge' evidence that they have an isomporphic representation of the graph; again, this either succeeds or fails. Also look at the SRP protocol, but the problem with this is that it's a patent minefield. See Practical Cryptography by Ferguson and Schneier. Jo

There's no way around it. As you said: if you cannot verify the source a man-in-the-middle attacker can replace anything the client receives, i.e. anything the client interprets and executes.

You say your only issue is a man in the middle modifying the javascript you use to perform a SHA1. I therefore guess you are using username + SHA1 of password for login....

That is completely insecure even with no Javascript tampering. Even though a man in the middle may not know the plain password if the javascript is not modified, he will know the hash, and he can perfectly use that hash to perform a login on his own by just replaying it.

Even if you include a salt / nonce, the man in the middle could still be able to use those tokens at the moment, and even steal the account by performing a password / email change.

Even ignoring this, and assuming you could actualy get around all that + actually get a javascript to test the integrity of a second javascript, how would you prevent that "verification script" from being tampered too? You keep depending on a script sent over an unsecure channel to assure security on such data (and could recursively go on for ever having a script that checks the integrity of a script that checks the integrity of a script...) all being perfectly tampered since they are sent over an unsecure channel.

The only way to do this would be to be able to build yourself a secure channel on top of http, which would need some client-side extras (a Firefox plugin / an ActiveX extension), but having native support for https that's just absurd.

as they are in the client you cannot access them.

This is the nature of the web pages...

try using important things in server side...

If your security architecture somehow requires functions to run in Javascript, then your security is flawed.

with JavaScript one can protect from passive network attacks (such as eavesdropping WiFi traffic), but you cannot protect yourself from active network attacks where the intruder is capable of controlling your HTTP response header and body data.

If you don't want to pay for the SSL certificate, you can create a self-signed certificate instead. However, this will only prevent passive network attacks, but is a lot easier than some hacky JavaScript implementations you ever create.

Essentially you need a CA signed SSL certificate to prevent active network attacks (a man in the middle).

You can only verify the integrity of Javascript files at the client if, and only if, server and client previously share a secret. That is most often not the case on the Internet. If such a secret is not available, then any attempt to verify transferred Javascript can be broken. It is a catch 22 situation.

Most often, people want to ensure JS integrity because it makes them feel like they can delegate security checks on the client side. In cryptography, there is a fundamental rule that should not be broken: never trust remote user input. Always double-check.

SSL/TLS can make middle-man attacks harder to achieve, but it is not watertight.