Carbonwallet.com
btc wallet (now under BTC.com)
Airbitz
Samurai Wallet
Turnkey Linux (with Electrum and/or Warpwallet address)
(fund the anonymous amount , then email a BIP38 protected wif key to cryptostorm ..pgp the passphrase perhaps ? )

Better yet.. besides what support has advised you could invest in Raspberry Pi's as a standalone hardware wallet or a secure OS platform do perform such purchases.

The irony is that the more you try to hide a transaction pertaining to token purchases the more you stand out to adversaries well capable of detecting it..

Do forgive me when some of the above begin clamping down on such usage in order to obtain tokens... the less frills you use the better ... more layers of obscuring also need more layers of opsec which isnt everybody's expertise

Hi Guys,

Seriously look into adding 'Paymentwall' as an option, they're easy to purchase in over 100 countries. I've purchase VPN subs b4 using them.

@Captain Blackberry
Obfuscation alone is usually a bad idea when it comes to security/anonymity.
Instead of selectively blocking certain scripts at certain domains, it would be a much better idea to simply disable WebRTC entirely so that if you miss something, or if someone finds some new (non-JS) way to make your browser access STUN/ICE servers, you won't leak any information.

While I don't know of any browser-specific tricks/vulnerabilities that allow STUN/ICE access, there are a lot of different application-specific URI schemes (I.e., torrent:// or bitcoin:) that get registered in most browsers by default when you install an application. Granted, most of the known vulnerabilities related to those types of schemes are specific to IE ( https://blog.cylance.com/redirect-to-smb ), and anyone using IE clearly doesn't give a shit about security or anonymity :-P

@df

As tariqh rightly points out with his WebRTC concern, it's the risk of scripts generally that trouble me.

Call it an exercise more than anything.
More obfuscation is good as it makes any correlations increasingly hard to make.

The worry is when you load up ipleak.net and see a simple script can invoke webRTC and expose my LAN IP, the tap IP, vpn IP, and maybe your real IP or web provider DNS.

Also lots of fingerprinting info.


I'm quite happy that you've managed to take Google out of the loop, Twitter can be blocked, and Swipe has to be a trusted entity.

Given a cryptofree connection and appropriately configured browser I'm quite happy now that I can get a token nicely.

Pre-paid CCs sound interesting. I'll have to look into those too.


Thanks for all the time spent responding to these concerns!

@Captain Blackberry
Stripe does have an API that we could use to create our own checkout system, but even that would still require JavaScript - https://stripe.com/docs/custom-form

The main reason we chose Stripe is because they're ran by more programmer types than the usual corporate/financial types you see at other payment providers (see https://github.com/stripe for proof of nerdyness), and because they seem to be fine with all of those pre-paid debit (gift) cards that PayPal likes to arbitrarily block.

We chose to use their pre-made Checkout because it's supported by more browsers, and it's relatively simple, and doing something similar in-house would require several hundred lines of code + many hours of testing, and it wouldn't provide any additional benefit because the same payment data would still be going to Stripe as it does now (from the customer's IP, not ours).

If you're simply trying to buy tokens anonymously, using Cryptofree or Tor would suffice.
There's really no need to have this ACL of things you're allowed to connect to, so long as you're not doing other things on those sites you're blocking from this same IP you're ordering from (I.e., logged into twitter and not blocking our twitter feed on the main page while ordering a token via BTC).

If you're trying to avoid state-level adversaries, then it would also be a good idea to only access your BTC wallet from a different IP (maybe a VM or Qube that's loaded with Tor and on a different exit than the one you're ordering from).

As for that P.S., I can refund the transaction if I have either the email address, blockchain transaction ID, or (I think) the BTC wallet address you sent from (or to). Just email me or PM me here.

Newbie here.

Used cryptofree as well, with firefox 51.0.1 with no script and WebRTC disabled, a mailinator address and Swipe and it was really slow (before DDOS attack).

The popup window eventually appeared, made the payment and the token appeared in the browser and received it as well through the email.

Swipe is a godsend as it accepts cc gift cards as it is a real hassle where I am located to purchase anonymously bitcoins.

I managed to get a 1 week token (a quick test so if it went wrong, not too much cash down)

I connected via Cryptofree. Created a guerrillamail temporary account (save the seed key and address to double check if you need to reload it!)

I just kept allowing all the stripe junk to run.

I also set Firefox to allow popup windows, since the Stripe is a popup Window.
I think this popup is what allows the web-page delivery of the token to appear rather than not, and relying entirely on the email delivery.

Also the popup brings up the QR code option.

The Firefox browser in question is pared back, so it's like vanilla at each load.

Only uMatrix was running.

I then paid via an iPhone and QR code from a phone based wallet (not a crappy online one!), connected via Cryptofree.

For thos running uMatrix here is the list that got me the token:

cryptostorm.is api.stripe.com * allow
cryptostorm.is b.stripecdn.com * allow
cryptostorm.is b.stripecdn.com frame allow
cryptostorm.is checkout.stripe.com * allow
cryptostorm.is checkout.stripe.com frame allow
cryptostorm.is cryptostorm.is * allow
cryptostorm.is js.stripe.com * allow
cryptostorm.is q.stripe.com * allow
cryptostorm.is q.stripe.com frame allow
cryptostorm.is stripe.com * allow
cryptostorm.is stripe.com frame allow
cryptostorm.is stripecdn.com * allow
cryptostorm.is stripecdn.com frame allow



Interestingly, as opposed to what you said df:
"""EDIT:
>>"Since there is no 'QR' payment system either, only an address, there is no trusted authentication (unlike the old Bitpay service)."

There is a QR feature in the Stripe checkout window though, just click that "Scan" button in the bottom right hand corning of the small window. That has nothing to do with trusted authentication though, nor did it whenever we were using Bitpay."""

Paying via QR code via the popup gave me the token within about 20s. The btc payment still hasn't confirmed.
Paying by QR, seems to allow the token to be sent well in advance of the confirmation.



So, a lesson to all trying to buy tokens for cryptostorm with btc.


Ideally I'd like to see a more robust system (more simple browser functionality), rather than having to run and rely on so much crap from Stripe.
Popups, CDNs, multiple domains, and many scripts, means you really have to have your wits about you if you want to get a token 'cleanly'


It'd be great to see a system that somehow utilises the open and hidden values within the blockchain to generate the cs keys automatically.
Ie, a payment to a provided address, and some specific of the senders details is the key.
I roll hex dice to then generate an address for example. That hash is visible to CS and is on the blockchain.
If that hash is allowable for a connection, then the original hex string would be a viable CS key?

Or something like that?



PS, any chance that the transaction I made, but the key I didn't get, can be reversed/reset?
If not fine, but I think it's important to ask. If I wanted PIA levels of anonymity and protection I'd be over there in a flash.
I want CS levels of anonymity but I also hope that you support that anonymity with the systems you use to sell the tokens without me losing money so easily!

Stripe's fraud prevention will sometimes mark an order as "escalated risk" if it comes from a VPN IP, but that only applies to CC orders. They don't have any fraud prevention for Bitcoin orders. Also, I have the fraud settings configured to only block orders when the "risk" is at the highest level (meaning it's definitely a fraudulent order. Like if someone tries using many different CCs to buy a bunch of tokens, but all from the same IP and browser, which would only happen if it were a lazy carder). I assume some CC orders will be coming from Cryptofree or Tor, so we're not blocking orders based solely on their IP.

I just checked on the primary Cryptofree server, it is running our DNS-based (/etc/hosts) ad-blocking, but I'm not seeing any Stripe IPs in the blacklist.

The stripe JS that our website includes is <script src="https://checkout.stripe.com/v2/checkout.js"></script>.
That code is updated often, so including it locally isn't an option since an update to it might break out checkout process.
I just looked through the code though, there's a few callbacks to q.stripe.com (which is just an alias for stripe.com), and a few more checkout.stripe.com callbacks.

From the primary cryptofree server:

[root@cf-i ~]# host checkout.stripe.com
checkout.stripe.com is an alias for stripecdn.map.fastly.net.
stripecdn.map.fastly.net has address 151.101.120.176

So they sometimes use fastly.net as a CDN. You should add stripecdn.map.fastly.net to your whitelist too, since that's most likely causing these speed issues you're having.
If you're doing IP-based blocking on your end, the network you should whitelist is 151.101.0.0/16 .
If you need something more specific, it appears that every time I resolve stripecdn.map.fastly.net from a different region, the response is always in 151.101.0.0/16 but also ends with .176.
Not sure if that's a coincidence though.

Thanks for the reply.

It seems javascript is useful at your end to assure things like masking email addresses from scrapers, but causes difficulty at the user end to assure no real IP data or fingerprinting is going on.
I was using my iPhone at the time I contacted you initially, the layout of the site goes well off on iPhone, and Fermi's address was the only one that appeared to pop up under emails.

I since emailed support from a proper computer.



I did use a vanilla FF profile (v46.0.1) to try access the Swipe service but it didn't work at all, so I can't think anything was being blocked or stopped. Perhaps a popup window? But there was no notification. Hmmm.

Could the cryptofree connection be causing issues for Google related scripts? I've noticed Google services not playing ball sometimes whilst connected via your VPN (asking for proof I'm not a robot etc).
Perhaps Swipe isn't happy either?


I'm just trying again now to at least get a Swipe page up using uMatrix. Sacking off all Google stuff from running is useful.
I'm just green-lighting all the cryptostorm and swipe addresses.

Twitter and Google Analytics shouldn't be needed should they?






Welllll, using cryptofree, the stripe connections seem stupendously slow.

I can connect here fine, and the payment selection page, but as soon as I'm turning on Swipe cdn and js stripe connections, the whole thing just stops responding.

I've tried 3 times now and waiting at least 5-10 mins each time and it just won't go anywhere.


Is the built in protections for ads and tracking etc in cryptostorm blocking some important stripe elements?

Or are stripe doing something to stop VPN users?

I just did a test order, Stripe works fine in Firefox, and in my previous tests all the other modern browsers were good with it too.

Most likely your issue is that you either have Javascript disabled, or you're also blocking https://ajax.googleapis.com/ajax/libs/j ... /jquery.js (our Stripe checkout uses jQuery).

I think the reason we included a google-hosted link to jquery.js is because we thought that would save us from having to update a locally stored jquery.js often since the remote one was likely to be more up to date, but I just checked and the one we're using hasn't been touched since 2013, so there's no real reason to do a remote include like this.

So I've replaced the HTML on the main page to NOT include jquery.js from that ajax.googleapis.com URL.
Instead, it will include a jquery.js that I just downloaded to the web server, so no more needing to whitelist any google hosts to order with bitcoin.
Just do a ctrl+F5 to refresh the page without loading from cache and everything should be fine.

If you're still getting that "Error: no Stripe token received." error, then either a browser addon is preventing the current javascript/jquery code from working, or you have javascript disabled, or you went directly to https://cryptostorm.is/stripe_1mo, or you refreshed the token delivery page.

EDIT:
>>"Since there is no 'QR' payment system either, only an address, there is no trusted authentication (unlike the old Bitpay service)."

There is a QR feature in the Stripe checkout window though, just click that "Scan" button in the bottom right hand corning of the small window. That has nothing to do with trusted authentication though, nor did it whenever we were using Bitpay.

OTHER EDIT:
Not sure why you were only able to see fermi's email address on the main webpage. Javascript is required in order for any of the email addresses to be displayed. Clicking on the spoon shows my email address (df@cryptostorm.is), and the "i" shows info@cryptostorm.is, and the life saver icon shows support@cryptostorm.is. Next to each email address (excluding info@) is a lock icon that links to our individual PGP keys if someone needs to send us an encrypted email. The reason I'm doing this semi-dynamic js/image style of displaying the email addresses is to help prevent automated email scrapers from easily obtaining our individual email addresses and spamming us.

So no joy in a vanilla Palemoon portable install.

Just looks to be loading then stops on the same token selection page.


Firefox vanilla is the same.


Firefox with uMatrix allowing just swipe/swipecdn, but not google, twitter and google analytics scripts running, and I get to this page:
https://cryptostorm.is/stripe_1mo

And this is the only content in plain text:
Error: no Stripe token received.


I'm logged on via cryptofree, so I'm not sure if that causes issues.

Given my desire to buy a token without my real IP being visible to god knows who via google, twitter and swipe etc, I'm not sure how else to buy a token anonymously.


If the in-browser delivery of the token worked it'd be great, but since it doesn't on Safari on an iPhone at least (the only place I got to even get to Swipe to pay via bitcoin), then the Swipe system is shit.


So I'm $18 down.

Cryptostorm is so 'cool' that it's impossible to use as described because they chose Swipe, which is fucking terrible.


I 'get' cryptostorm, that's why I've been a user for so long. But throw me a bone here.
I can't get excited about being a customer if you can't provide an anonymous way to buy your tokens.

I tried on the iPhone which worked ok.

I used a guerrillamail web address for the token to go to.

But the new 'swipe' bitcoin payment also suggests you'll get a web provided token.

Since there is no 'QR' payment system either, only an address, there is no trusted authentication (unlike the old Bitpay service).

I seemed to hit a long authorisation time spike the other evening.

So in the end my crypto-free VPN connection seemed to have issues with guerrillamail over the 5-6hrs for authentication and it timed out. (my problem, but it seemed the stored 'seed' didn't allow me to connect to the same email box again)

However there was also no web-provided key. After going via the swipe 3 month token process and pressing pay, I just went back to the main page where you choose token purchase options.


So I'm ~ $19 down as of this point.

I emailed fermi (only address I could find via the main page) but I've had no reply yet.

I'm sure if they have the bitcoin payment, they know the token? So they can reset the token, or block it, and provide a new one?
Or refund me and block the token that I never got?


Either way, the new Swipe system is imo shite.

By requiring a robust (non disposable) email address you may as well just tell the whole world you're buying a token for cryptostorm VPN.
If the authentication takes an age, and the web-based delivery of the token doesn't work (does it?!), then the whole idea of buying a token discretely is not possible.

That's a big fail at the first hurdle.


I'll give it another try but with a 1 month token this time.


But I think cryptostorm need to up their game on bitcoin payments.

If you sell the bitcoin purchase option as great for anonymity, but then allow no way to use it anonymously, it's a non-selling point.

@OP

Could you try buying it on a completely different device? If that doesn't work then it's definitely a back-end issue, and I would ping staff at support@cryptosatorm.is.

As for other resellers, they seem to have dried up.

The main cryptostorm page central box for bitcoin purchases. It just sits there and does nothing, or it says a swipe/key wasn't passed or something in plain text.

Either way I can't buy a token unless I use paywank or credit scam cards.

Is this a bug, the new bitcoin payment system down? The page badly configured?


I've logged on via cryptofree and it's painfully slow so I'm not sure if that is impacting anything.
I'm also avoiding cookies, scripts etc, but even in a 'vanilla' FF browser it's not working.

I checked in the 'resellers' thread, but I can't seem to find any resellers in there.


My token has run out, and I do most of my 'browsing' on an iPhone, so the added filtering/blocking and anti-tracking features of cstorm are most welcome and I use the VPN perpetually on the device.

Being without it isn't ideal really.

Buying tokens is still the hardest part of the whole process.