383400 - Expose nsICryptoHash to web content

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement)

Description

[Chris Granade]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: 

Whereas the functionality of nsICryptoHash could be quite useful to scripts, and is hard to implement directly in JavaScript, it would be very helpful to have some object accessible by scripts that exposes the functionality.

Reproducible: Always

Comment 1

[:Gavin Sharp [email: [e-mail]]]

nsICryptoHash is already "exposed to scripts". Do you mean exposing an object with a simpler API? Or just a wrapper, like http://lxr.mozilla.org/seamonkey/source/toolkit/components/url-classifier/content/moz/cryptohasher.js ?

Comment 2

[Chris Granade]

I suppose I should have been clearer. Sorry about that. Anyway, what I meant by "exposed to scripts" was that untrusted JS code should still be able to generate cryptographic hashes through nsICryptoHash (or a wrapper thereof). Systems like Blackboard (powers http://classes.uaf.edu/ and other such sites) use a JS implementation of MD5 to hash passwords before sending them to the server.

Currently, it is hard to upgrade systems like that to a more robust and secure hash algorithm, since that would involve reimplementing a different algorithm in JS or using LiveConnect to connect to the JCE. The latter option relies, however, not just upon the Gecko engine, but also upon the user having a suitable JRE and JCE provider installed.

Thus, providing a wrapper like the one you linked to would reduce the external dependencies that a site would need to assume that a user meets. Whereas it is a (relatively) simple matter to branch between Firefox and MSIE or other non-LiveConnect enabled browsers, it is harder to progmatically determine the JRE and JCE versions.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Oh - you mean expose the functionality to web content. That wasn't clear, I thought you were speaking about chrome JavaScript code.

Comment 4

[Alex Vincent [:WeirdAl]]

Category manager, "JavaScript global property" :)

Comment 5

[Chris Granade]

Perhaps an extension would be a good way to prototype the functionality? If so, then a wrapper would have to expose itself to web pages, a la the console object exposed by Firebug.

Looking at how Firebug exposes console, it seems that the methods Firebug.watchWindow and Firebug.unwatchWindow (see http://fbug.googlecode.com/svn/trunk/content/firebug/firebug.js) would do the trick. That said, I've never written a Firefox extension before, so I would appriciate it if someone could let me know if I'm on the right track.

Comment 6

[Eric Jung [:ericjung]]

There are a slew of open-source javascript hashing implementations available on the web for MD4, MD5, RIPE-MD, SHA-1, SHA-256, SHA-384, SHA-512, etc. So why do we need to expose this internal interface (nsICryptoHash) to untrusted code?

Websites can (and already do) include whichever implementation they like and have the browser execute said code to generate hashes. Those hashses can (and are) be sent to a server through normal channels. As for upgrading to another hash algorithm, under the status quo it's simply a matter of a website swapping out the included javascript file and changing their server-side code to use the new hash algorithm.


IMHO, you haven't made a case why nsICryptoHash should be exposed to untrusted code. What's wrong with the status quo?

Comment 7

[Chris Granade]

As mentioned by Paul Johnston at http://pajhome.org.uk/crypt/md5/, JavaScript crypto does work, but it has several problems:

"Over the web, JS cryptography can only protect against passive eavesdropping, as the JavaScript itself is downloaded over an insecure link. If an attacker can modify network traffic, they can make malicious changes to the JavaScript code.

"In any case, JS interpreters are not designed for secure programming. They may leave sensitive information lying about in memory. They're too slow for some algorithms, e.g. BSD-style MD5 passwords, or RSA with full-size keys. Bitwise operations are buggy in several implementations."

Thus, my proposal for exposing nsICryptoHash (or a wrapper thereof; what I want is the functionality) is motivated by a few basic points:

1) Convenience. It's easier to just use window.crypto.hash(var) than to find a good hash function online.

2) Security. By reducing the amount by which a page relies on external content, a site can be made more securely. Moreover, if a bug is found in an ad-hoc hash function that results in a memory leak, then there is no good way to "push" an update. Another way this improves security is by keeping possibly sensitive (unhashed) data inside well-audited code that is less likely to have memory leaks.

3) Functionality. By providing the hashing functionality that I proposed, it becomes easier to write web pages that are more functional. Developers tend to do what is convenient, and so the convenience rationale naturally leads to the notion that exposing hashing functionality will encourage more websites to use it.

All of this aside, it may not be appropriate to expose nsICryptoHash. If that is the case, then I am sorry to waste everyone's time with this. I acknowledge that I am not a Firefox dev, nor even an extension developer, and thus may simply be incorrect in my reasoning by means of a lack of knowledge about building browsers.

Comment 8

[Eric Jung [:ericjung]]

(In reply to comment #7)
> As mentioned by Paul Johnston at http://pajhome.org.uk/crypt/md5/, JavaScript
> crypto does work, but it has several problems:
> 
> "Over the web, JS cryptography can only protect against passive eavesdropping,
> as the JavaScript itself is downloaded over an insecure link. If an attacker
> can modify network traffic, they can make malicious changes to the JavaScript
> code.
> 

This is what HTTP over SSL is for (HTTPS). I know you'll pull out the old man-in-the-middle card so have at it.

> "In any case, JS interpreters are not designed for secure programming. They may
> leave sensitive information lying about in memory. They're too slow for some
> algorithms, e.g. BSD-style MD5 passwords, or RSA with full-size keys. Bitwise
> operations are buggy in several implementations."
> 

I don't agree. I've worked with Paj (Paul Johnston) before--he's contributed to my PasswordMaker extension--and JS hashing in the extension is quite fast. Of course this depends on your hardware, and it won't be as fast as hashing in C++, but for the application you're talking about (password hashing), JS is more than adequate. Give PasswordMaker a try if you don't believe me.

> Thus, my proposal for exposing nsICryptoHash (or a wrapper thereof; what I want
> is the functionality) is motivated by a few basic points:
> 
> 1) Convenience. It's easier to just use window.crypto.hash(var) than to find a
> good hash function online.
> 

Agreed. It's also easier to write window.addBookmark("FooBar", "http://foobar.com/") as well as countless other shortcuts. Why aren't they implemented in the browser?

> 2) Security. By reducing the amount by which a page relies on external content,
> a site can be made more securely. Moreover, if a bug is found in an ad-hoc hash
> function that results in a memory leak, then there is no good way to "push" an
> update.

Why not? An update can be pushed to the browser simply by changing the JS hashing code on the web server.

>Another way this improves security is by keeping possibly sensitive
> (unhashed) data inside well-audited code that is less likely to have memory
> leaks.
> 
> 3) Functionality. By providing the hashing functionality that I proposed, it
> becomes easier to write web pages that are more functional. Developers tend to
> do what is convenient,

If this were true, every website with a login would use SSL. Interestingly, Yahoo! (who uses Paj's MD5 JS implementation) did all logins over plain HTTP until sometime late 2006. Now login attempts occur over SSL. 
 
> All of this aside, it may not be appropriate to expose nsICryptoHash. If that
> is the case, then I am sorry to waste everyone's time with this. I acknowledge
> that I am not a Firefox dev, nor even an extension developer, and thus may
> simply be incorrect in my reasoning by means of a lack of knowledge about
> building browsers.
> 

You might be interested in Firefox Link Fingerprints. They don't solve the problem you're trying to solve, but given your liking for hashing, I'm sure you'd like it. See http://www.gerv.net/security/link-fingerprints/

Comment 9

[Benjamin Smedberg]

There is no web spec for this, and bugzilla is not the right place to advocate for one. Please feel free to propose something to the WhatWG mailing list, but you will need to have very precise use cases and reasons why JS implementation are insufficient to get any agreement.