Auto-validating bitaddress.org, bitcoinpaperwallet.com, brainwallet.org, etc.

[canton]

Hi, developer of bitcoinpaperwallet.com here.

I'm looking for feedback on an idea I have for a self-service "website validator" for people who insist on running live financial transactions off of live websites like bitaddress.org, bitcoinpaperwallet.com, etc.

The problem

• The only safe way to run one of these services is by downloading the ZIP file from Github and verifying the SHA1 or PGP signature against what's been published.
• This is fine for developer/nerd types, but definitely not something within my mom's skillset. She has BTC, and I'd like it if she could secure them herself.
• My mom is capable of running bitaddress.org in a browser, but there's no way telling if the website has been hacked and is serving up a malicious/compromised wallets.
  

A solution?

• Someone *other* than one of the developers of bitaddress.org, bitcoinpaperwallet.com, etc. deploys a brand new website, maybe called 'bitcoinwebservices.com'.
• This website displays a list of all the popular bitcoin-related web services along with their latest published SHA1 sums (automatically scraped from github READ ME files?)
• Each site has a "VISIT" button next to it. When you click the visit button two things happen: 1) a new window pops up with the destination site loaded over HTTPS, and a moment later 2) javascript is used to retrieve the same HTML from the same website and compute a SHA1 sum and compare it against the published SHA1 sums.
• If the published SHA1 sum matches what your browser shows as the SHA1 sum, this means it's safe to visit that site, and a "VERIFIED SAFE TO USE" badge appears next to the "VISIT" button.
  

So this site would really have a dual purpose:

1) It serves as a directory of popular bitcoin-related web services, and
2) It erects a roadblock in that a hacker would have to compromise both a bitcoin web service AND the 'bitcoinwebservices.com' website (or the github repo) in order to attack live web users.

Any thoughts on this idea? And a reminder, this is absolutely not about replacing the recommendation that users download the github ZIPs. This is merely a proposal to help safeguard what we all know is happening in the real world: that my mom (and maybe yours!) are using live websites to print paper wallets and transact with bitcoin.

[mikewoods]

Hi, I'm developer of offlineaddress.com.

To be able to develop secure bitcoin services we need a way to allow developers to prove security of their sites, without hurting usability for average bitcoin users.

Validating service could be generalized and also useful to sites that aren't related to bitcoins.
It might sense to contact:
 - GitHub.com
 - EFF.org
 - TorProject.org
because it seems to me that they might want to solve similar problems.

Solution could be:
 - third site, as described by canton (general, or specific to bitcoin sites).
 - browser plugin that compares checksums automatically on each visit, for sites with specified meta tag with link to the source.

[zemario]

Hi, I'm developer of offlineaddress.com.

To be able to develop secure bitcoin services we need a way to allow developers to prove security of their sites, without hurting usability for average bitcoin users.

Validating service could be generalized and also useful to sites that aren't related to bitcoins.
It might sense to contact:
 - GitHub.com
 - EFF.org
 - TorProject.org
because it seems to me that they might want to solve similar problems.

Solution could be:
 - third site, as described by canton (general, or specific to bitcoin sites).
 - browser plugin that compares checksums automatically on each visit, for sites with specified meta tag with link to the source.

Signed browser plugins with hardcodded checksums sound like the most practical/obvious solution.
I also think it is important that the code is not ofuscated or minimized. And if possible keeping it simple. Loading enormous libraries becomes more prone to errors and requires more work verifying.

[canton]

Signed browser plugins with hardcodded checksums sound like the most practical/obvious solution.

I mostly like this idea, however 'hardcoded checksums' sounds like it could be a pain since many of these projects are updated every couple months. Any way to make the checksums more flexible?

[cr1776]

Perhaps this should be looked at as a peer to peer issue instead of a web site or hard coded address. This prevents single points of failure.  Perhaps something built on namecoin, bit message or the like (this is very off the cuff, but doing it in a distributed manner is important I think.)

Other projects could find this useful for sure.

[canton]

Perhaps this should be looked at as a peer to peer issue instead of a web site or hard coded address.

Ultimately I like this type of idea since centralization is anathema to bitcoin. However, the problem I'm specifically interested in is making bitcoin web services more secure for novices who are unlikely to download ZIP files and do checksums themselves. Installing P2P software would likely be beyond this target group's skill strengths as well.

Maybe instead of a brand new centralized service, this could be something as simple as a single portal/checksum page hosted on a reputable site such as bitcointalk.org or bitcoin.it.

[cr1776]

Perhaps this should be looked at as a peer to peer issue instead of a web site or hard coded address.

Ultimately I like this type of idea since centralization is anathema to bitcoin. However, the problem I'm specifically interested in is making bitcoin web services more secure for novices who are unlikely to download ZIP files and do checksums themselves. Installing P2P software would likely be beyond this target group's skill strengths as well.

Maybe instead of a brand new centralized service, this could be something as simple as a single portal/checksum page hosted on a reputable site such as bitcointalk.org or bitcoin.it.

Simple is key as you state.

Using the web site idea in the initial post, perhaps each site could query the distributed hash for a particular web site.  Each of the of sites could continually verify that none of the others have been compromised. E.g. Main site checks each of the others, but the others continually check other sites in the network against their hashes.

The more sites running the extra bit of code the stronger the guarantees that all are safe.

You could have a plugin available for those who are technically advanced to automatically verify every site.

[jl2012]

Good idea. I suggest to create a validatebitcoinwebservices.com to make sure bitcoinwebservices.com is not compromised, and a validatevalidatebitcoinwebservices.com to make sure validatebitcoinwebservices.com is not compromised, and a validatevalidatevalidatebitcoinwebservices.com to make sure validatevalidatebitcoinwebservices.com is not compromised, and a validatevalidatevalidatevalidatebitcoinwebservices.com.................. 

[gmaxwell]

What you really want is a generic validatorvalidator  to act as a fixed point, then you can feed it to itself and once it passes, feed the normal website validator to it.

Or you could not do high value crypto in an environment where its the norm for people to replace the code out from under you at any time.

[mikewoods]

Browser plugin solution tied to web site seems like a nice combination.
...

EDIT:
We have to decide on common solution.
Check out canton's proposal below.

[canton]

Each website could have meta tag like this...

I'm a little confused on this... If I'm a hacker and I compromise a site, wouldn't I just remove the meta tag so that verification is skipped?

It seems to me that if a browser-plugin solution were in place, the plugin could just have knowledge of which sites can be verified, irregardless of whether or not the sites had any particular meta tags in place.

I have a feeling I'm missing something here so feel free to expand.

Meanwhile, here's an expanded bit on my "portal" idea:

Anyone who wants their website to be checksummable submits three things to the portal project:

1) Name / Description / Purpose of project
2) URL for github landing page, e.g. https://github.com/pointbiz/bitaddress.org/
3) URL for published project, e.g. https://bitaddress.org

Somewhere in the github READ ME, the author must include a line that's formatted for scraping, something like this:

PUBLIC WEBSITE SHA1-HASH: 364542f1ccc5777c79aebb1692a6265cf3e42e7e

And I think that's it. Anytime they update the public site, they just need to be sure to update the READ ME file on github.

Meanwhile, the portal site wouldn't need updating at all. When invoked, the "portal" website would use PHP to pull off the latest READ ME for each project and scrape the PUBLIC WEBSITE SHA1-HASH, store it in a javascript array.

Then, when someone clicks "LAUNCH/VERIFY" for any of the listed websites, 1) The website opens in a new window/tab, and a moment later, 2) javascript uses the visitor's IP connection to pull down a duplicate copy of the HTML, run a SHA1 in javascript, and then display the "VERIFIED!" or "Uh oh, SHA1-HASH in READ ME doesn't match hash I just retrieved."

There's one bit of cleverness in here (if I do say so myself) is that we circumvent a smart hacker from modifying bitaddress.org in such a way that it serves up unadulterated HTML to IP addresses belonging to any particular user agent or IP.

However there's one detail I haven't solved yet.

If I'm a *really* smart hacker, what I'll do is modify bitaddress.org so that when I receive a request from any brand new IP address, I always serve up the hacked version. When I receive subsequent requests from the same IP (presumably for checksumming purposes) I always serve up the unhacked version so that I pass the test.

Even if I we randomize whether we use the first request to display the tab and the second request to do the checksum, or visa-versa, a hacker will still like the 50% odds of escaping detection.

The only semi-solution I can think of so far is that when a "Uh oh, hash doesn't match" situation arises, a button is displayed (or automatic redirect is fired) that allows the user's session to invoke a shut down / warning for that particular site on the portal. This would add a notice (maybe notify the developer!) that a mismatch has occurred. This way each person who uses the portal is volunteering their own computer/IP as a sentry to safeguard to warn other users. Maybe a three strikes and you're out thing where three mismatches in a 24 hour period unlists the website until a developer intervenes.

[kezzyp]

I like your services and i do hope more development take place for security, your services are great!

[pointbiz]

canton, I like you train of thought and I'm pondering this proposal. We need to keep in mind that JavaScript will send different headers to the web server than opening the site in a new tab/window with _blank.

I also like what gmaxwell said about a generic validatorvalidator. I'm trying to understand exactly how we'd implement that.

1) validatorvalidator loads itself and validates it's good (not sure how).
2) Then it loads the SHA1/256 checksum validator and validate that (not sure how).
3) Then you feed the URL of bitaddress.org/bitcoinpaperwallet.com and SHA1/256 checksum to the validator (through clicking a link etc.)
4) Then? document.write the valid HTML contents out to the current browser window and make sure the JS inside executes?

... not sure how to make the above work ...

[canton]

We need to keep in mind that JavaScript will send different headers to the web server than opening the site in a new tab/window with _blank.

Well crap, I hadn't thought of that. This would scuttle the whole idea, if a compromised site could detect the difference between JavaScript grabbing the HTML for verification vs. the browser loading it up for typical use. Can anyone think of a solution so that a JS request for the HTML vs. the browser's natural new tab loading are indistinguishable?

[pointbiz]

We need to keep in mind that JavaScript will send different headers to the web server than opening the site in a new tab/window with _blank.

Well crap, I hadn't thought of that. This would scuttle the whole idea, if a compromised site could detect the difference between JavaScript grabbing the HTML for verification vs. the browser loading it up for typical use. Can anyone think of a solution so that a JS request for the HTML vs. the browser's natural new tab loading are indistinguishable?

I take back what I said

I think it's just the default headers in jQuery that put an X-Requested-With header. We should be able to control the headers that are set.

[zemario]

Signed browser plugins with hardcodded checksums sound like the most practical/obvious solution.

I mostly like this idea, however 'hardcoded checksums' sounds like it could be a pain since many of these projects are updated every couple months. Any way to make the checksums more flexible?

Not being 'flexible' is what makes them useful. This means that the websites should not be updated regularly. To be fair, you do have to follow a policy of seldom updates if you want to provide a strong sense of trust on the users.
If the checksum is presented to the user, after a while (s)he gets familiar with it. If you provide a link to a specific revision on github, the users could manually check the code once and rely on the checksum from that point on. Then, seeing the same checksum every time would make them familiar with it, and it would raise suspicion if something else shows up.

Scheduled and seldom site updates are not convenient for the site maintainer, but in the end, what we want is a site which content we know.
If your site states: "next scheduled update: mars 15", then on mars 15 I would be cool if the checksum is not the one I usualy see. Then I could head up to bitcointalk.org and see the new checksum signed by the same pgp key.