Bitcoin Forum
June 16, 2019, 12:05:26 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Auto-validating bitaddress.org, bitcoinpaperwallet.com, brainwallet.org, etc.  (Read 2036 times)
canton
Sr. Member
****
Offline Offline

Activity: 259
Merit: 267



View Profile WWW
January 13, 2014, 05:30:33 PM
 #1

    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.
1560686726
Hero Member
*
Offline Offline

Posts: 1560686726

View Profile Personal Message (Offline)

Ignore
1560686726
Reply with quote  #2

1560686726
Report to moderator

0% MINING FEES FOR THE NEXT MONTH. GET PAID IN BTC, ETH, XMR or RVN.

www.cudominer.com Learn More
Easily run CudoOS from a USB flash drive.
Designed for rigs. Manage your mining remotely from Cudo Console.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
mikewoods
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile WWW
January 13, 2014, 08:23:38 PM
 #2

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
Full Member
***
Offline Offline

Activity: 194
Merit: 100


View Profile
January 13, 2014, 09:58:53 PM
 #3

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
Sr. Member
****
Offline Offline

Activity: 259
Merit: 267



View Profile WWW
January 13, 2014, 10:27:14 PM
 #4

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
Legendary
*
Offline Offline

Activity: 2268
Merit: 1017


View Profile
January 14, 2014, 01:01:23 AM
 #5

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
Sr. Member
****
Offline Offline

Activity: 259
Merit: 267



View Profile WWW
January 14, 2014, 02:17:39 AM
 #6

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
Legendary
*
Offline Offline

Activity: 2268
Merit: 1017


View Profile
January 14, 2014, 02:29:05 AM
 #7

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
January 14, 2014, 02:41:23 AM
 #8

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..................  Roll Eyes

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2758
Merit: 2308



View Profile
January 14, 2014, 04:43:04 AM
 #9

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
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile WWW
January 14, 2014, 06:10:20 AM
Last edit: January 15, 2014, 06:04:11 AM by mikewoods
 #10

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
Sr. Member
****
Offline Offline

Activity: 259
Merit: 267



View Profile WWW
January 14, 2014, 07:12:00 PM
 #11

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 15, 2014, 08:21:01 PM
 #12

I like your services and i do hope more development take place for security, your services are great!
pointbiz
Sr. Member
****
Offline Offline

Activity: 433
Merit: 257

1ninja


View Profile
January 16, 2014, 04:11:15 AM
 #13

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 ...

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
canton
Sr. Member
****
Offline Offline

Activity: 259
Merit: 267



View Profile WWW
January 17, 2014, 08:52:37 PM
 #14

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
Sr. Member
****
Offline Offline

Activity: 433
Merit: 257

1ninja


View Profile
January 20, 2014, 01:37:17 AM
 #15

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 Tongue

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.

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
zemario
Full Member
***
Offline Offline

Activity: 194
Merit: 100


View Profile
January 21, 2014, 04:30:05 AM
 #16

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!