These wallet servers will be kept up to date on the latest version of Counterwallet, Counterparty, and Counterblock.
Public Development Servers
We have also setup public counterparty and counterblock development servers which developers can use to interact with Counterparty and Counterblock without the hassle of setting up and hosting your own counterparty server.
This is great and kudos to coindaddy.io … but is there a risk of noob users being unsure which servers can be trusted if more than a few pop up? I wonder it would be too trivial to hack a difference that compromises wallets and sends data to server. What stops simple spoofing a honey trap password box?.. Are we limited to knowing which are trusted hosts?.. Is counterparty listing those it know are genuine; that doesn’t seem a good answer?.. or is it simply undoable, in which case is there a FAQ that we can know about to point that out?
This is a great question, and one of the first things I asked the CP Devs about when I was considering hosting a wallet. What is there to prevent someone from modifying the counterwallet webpage to insert some javascript or something that captures the 12-word passphrase when a user logs in. The response I got was basically that the counterwallet files are hashed when installed and files are checked against their known good hash before they are allowed to load.
In this manner you can ensure that if someone hacks the server and injects some javascript or something into the page to try and do bad stuff, the file will not be served/loaded. I’m sure one of the CP devs should be able to answer better than I
The hashes (stored in a .bowerhashes file in the CW repo) allow us to freeze/checkpoint the dependencies that counterwallet builds with.
A restrictive Content Security Policy (CSP) in place prevents malicious JS code (for instance) from running and shipping things like passphrases off to external sites, as well XSS issues, injection attacks, and other potential attack vectors.
Moreover, the cw servers themselves have numerous security measures to prevent and detect unauthorized access and changes.
However, none of this prevents the authorized site owner him/herself from modifying these files in a malicious manner, in a way that complies with the CSP (or disabling the CSP).
For the best current defense against this, anyone is welcome to go to/use https://counterwallet.coindaddy.io/src/ instead, and manually inspect the javascript resources itself (the /src/ suffix will utilize the raw JS/CSS sources, instead of optimized/minified ones). That way, one can ensure that the code hasn’t been tampered, client-side JS checks are still in place, and more. One can also check (via the browser’s developer console) that the necessary HTTP headers (e.g. Content-Security-Policy, etc) are coming across the wire and are intact.
Unfortunately, the above is currently the best way to be sure AFAIK. What would be best is for someone to write a tool that anyone could run that would pull and compare the source files between one cw server (e.g. counterwallet.io) and other (e.g. counterwallet.coindaddy.io). The tool could also check the returned HTTP headers to ensure the CSP header is present, as well as the other security-related headers we use. It could run periodically, and possibly alert if there were differences detected. Running through tor or some proxy network would also be a benefit, to avoid the chance that a sophisticated malicious site owner would serve “clean” files to the (known) IP of the checking host, while serving “dirty” files to everyone else.
There should be tools out there that can probably do this already, but they would just have to be configured for the task.
That’s very encouraging, though I don’t understand how the /src/ are limited from a simple overwrite after the nasty has compiled. Obviously, the more that real money is involved, the more likely all kinds of attacks will be made and those with more skills and imagination than I have.
I wonder another route would be to allow only servers that have been built by Counterparty and then with some rubber stamp or internal call home to cross check some timing hashing security that would be impractical to hack. Then only trusted hosts like perhaps CoinDaddy would stand as the core alt in the case of counterwallet.io having a problem.
If you use /src/, you are pulling the source files right off the box and rendering the website via that. “/” is just taken from /src/ via the build process. Even if “/” is clean, if /src/ is modified after the build, if you check “/src/” once you load the site, you’ll still be able to tell that they’re modified.
Counterparty itself doesn’t have the resources to check and certify 3rd party CW servers. The best that could happen would be the creation of a robust CW verification tool. This tool could also be used to periodically check all CW servers (even ours) and alert/flag potential security issues (e.g. compromised servers, etc) caused by someone other than the site operator, that got through all other defenses (small chance, but always a chance, especially if the operator didn’t security harden the box, disabled checks, etc)
I got to use this server for the first time last when when i could not access the standard servers. This is great that we have an alternative to counterwallet
