4 ms·

If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high ba

If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high bar

nwah1 8y ago
There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.
- vedantroy 8y ago
  I don't think the Javascript for authentication can be client-side. Authentication of passwords must be done on the server.
  - vesinisa 8y ago
    Did you read the article? The system is designed so that an authentication token is derived from the password, and this token, rather than the password itself, is authenticated against on the server. Since the encryption key can not be derived from the authentication token, this shields the content of the encrypted data the server stores from itself. GP rightly noted that deriving the authentication token with code served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.
    - maccard 8y ago
      > unless user has the time to verify the JavaScript they are served every time they log in. Which is once per install, the same amount of times then user would have to verify the native code
      - vesinisa 8y ago
        There's actually a great difference, because for binary distribution it simply suffices that the user verify the cryptographic hash of the binary they downloaded. Then they can be confident that they were served the correct publicly distributed binary, and not a subverted version. JavaScript by its very nature can not be easily, if at all, verified. Even if you verify that you are being served the same code as other users and the code is not subverted at one point in time, it's very much expected that the code may change at any time at the web developer's discretion. This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.) Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..
        maccard 8y ago
        > JavaScript by its very nature can not be easily, if at all, verified. Yes it can, in the same way you mentioned in your previous paragraph. Mozilla post the hash of the JS source file, and any user who wants to can verify the hash of the source file they have can do so in exactly the same way they verify a binary. It's literally calling sha1sum on the js file isntead of the binary. > This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.) I'd partially agree here - it's implemented like this so that they can update sync without updating the browser. If there's an issue found, mozilla can fix it, change the JS that is being served, and update the hash of the file. Sync branding (to me) has nothing to do with it. > Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it.. Yes, but this is moving the goalposts from the user verifying the js. This is true whether the code is in the binary or not. If the code goes in the binary, and is shown as part of the DOM, you need to modify the DOM logic to ensure nothing else can see it.
- kbenson 8y ago
  > Maybe an intermediate solution would be to use integrity hashes on the remote calls. That was my immediate thought upon reading your comment and realizing that the bar to hit is really to be just as secure as if it's baked in the binary, but on reading the bugzilla links that _rfk posted in a comment to your original comment, I'm not sure it really works for their goals (whether or not you think those goals are correct or match yours). If I maybe understand what they are working towards, it's having the flexibility to provide fixes/features quickly while still providing security. I'm not sure the features portion of that is as important as the credit they give it, given we're talking about security here, but quick fixes is good. I imagine they are looking at a way to provide a specialized context or something similar to lock down what can and cannot be done if the served content is malicious, but I'm not entirely sure what that would look like.
mmirate 8y ago
On larger Linux distributions, the trust is less with Mozilla and more with the distro-package maintainers - use of dynamically remote-loaded JavaScript here shifts the trust back to Mozilla; if you trust your maintainers but not Mozilla, then this is a problem.
- AsyncAwait 8y ago
  You really need to trust both. A browser vendor has so many layers to attack you, if they're malicious, that there's no way around it. Same for package maintainers.
rauhl 8y ago
Not really, since one can verify the Firefox code oneself, or hire others to do it, or rely on the fact that it’s a matter of public record and do forensics analysis after the fact should one be compromised. But a target JavaScript file sent only to oneself a single time … that’s practically impossible to validate or prove.
- IshKebab 8y ago
  Most people download Firefox binaries directly from Mozilla. They can't verify the code (even if they knew how).

If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high bar

nwah1 8y ago

There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.

vedantroy 8y ago
I don't think the Javascript for authentication can be client-side. Authentication of passwords must be done on the server.
- vesinisa 8y ago
  Did you read the article? The system is designed so that an authentication token is derived from the password, and this token, rather than the password itself, is authenticated against on the server. Since the encryption key can not be derived from the authentication token, this shields the content of the encrypted data the server stores from itself. GP rightly noted that deriving the authentication token with code served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.
  - maccard 8y ago
    > unless user has the time to verify the JavaScript they are served every time they log in. Which is once per install, the same amount of times then user would have to verify the native code
    - vesinisa 8y ago
      There's actually a great difference, because for binary distribution it simply suffices that the user verify the cryptographic hash of the binary they downloaded. Then they can be confident that they were served the correct publicly distributed binary, and not a subverted version. JavaScript by its very nature can not be easily, if at all, verified. Even if you verify that you are being served the same code as other users and the code is not subverted at one point in time, it's very much expected that the code may change at any time at the web developer's discretion. This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.) Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..
      - maccard 8y ago
        > JavaScript by its very nature can not be easily, if at all, verified. Yes it can, in the same way you mentioned in your previous paragraph. Mozilla post the hash of the JS source file, and any user who wants to can verify the hash of the source file they have can do so in exactly the same way they verify a binary. It's literally calling sha1sum on the js file isntead of the binary. > This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.) I'd partially agree here - it's implemented like this so that they can update sync without updating the browser. If there's an issue found, mozilla can fix it, change the JS that is being served, and update the hash of the file. Sync branding (to me) has nothing to do with it. > Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it.. Yes, but this is moving the goalposts from the user verifying the js. This is true whether the code is in the binary or not. If the code goes in the binary, and is shown as part of the DOM, you need to modify the DOM logic to ensure nothing else can see it.
kbenson 8y ago
> Maybe an intermediate solution would be to use integrity hashes on the remote calls. That was my immediate thought upon reading your comment and realizing that the bar to hit is really to be just as secure as if it's baked in the binary, but on reading the bugzilla links that _rfk posted in a comment to your original comment, I'm not sure it really works for their goals (whether or not you think those goals are correct or match yours). If I maybe understand what they are working towards, it's having the flexibility to provide fixes/features quickly while still providing security. I'm not sure the features portion of that is as important as the credit they give it, given we're talking about security here, but quick fixes is good. I imagine they are looking at a way to provide a specialized context or something similar to lock down what can and cannot be done if the served content is malicious, but I'm not entirely sure what that would look like.

mmirate 8y ago

On larger Linux distributions, the trust is less with Mozilla and more with the distro-package maintainers - use of dynamically remote-loaded JavaScript here shifts the trust back to Mozilla; if you trust your maintainers but not Mozilla, then this is a problem.

AsyncAwait 8y ago
You really need to trust both. A browser vendor has so many layers to attack you, if they're malicious, that there's no way around it. Same for package maintainers.

rauhl 8y ago

Not really, since one can verify the Firefox code oneself, or hire others to do it, or rely on the fact that it’s a matter of public record and do forensics analysis after the fact should one be compromised. But a target JavaScript file sent only to oneself a single time … that’s practically impossible to validate or prove.

IshKebab 8y ago
Most people download Firefox binaries directly from Mozilla. They can't verify the code (even if they knew how).