Say I want to create a Bitcoin exchange or an e-wallet service and make it as secure as possible. Assuming the nature of the service results in more Bitcoin deposits coming in then Bitcoin leaving the system out, yet the need to allow instant withdrawals of Bitcoins out of the service, I thought of the following scheme or scenario.
Create on a separate computer a list of 1000 Bitcoin addresses using Multibit. Transfer those 1000 public keys to DB on web server using a USB, to a table holding a pool of free/non-used addresses. When a member creates an account I assign a free Bitcoin deposit address to make member account funding possible. Since the private key for these 1000 deposit addresses is not on the web server or DB (generated on another computer and only public keys were imported using USB) I am pretty much secure that all funds coming into the system as deposits are safe.
When a member wishes to trade with another member, I simply maintain my own balance accounting system, by creating tables and logging transfers from one member account to another.
When a member wishes to withdraw his Bitcoins, I will use a Hot wallet which would only accept requests from the web server IP address, check my internal accounting system to make sure member has enough balance left and make payments from the hot wallet to whatever external Bitcoin address withdrawal has been requested to. By making sure I keep no more than, say, 5% of overall balance on the hot wallet, any security breach will not result in 100% loss of site funds.
How secure is this scheme? Would you suggest I do things otherwise?
Yes, you can use such scheme, but make sure you're keeping those private keys for 1000 wallets in secure place. I would recommend encrypting all of those initial 1000 private keys with some master password which you'll never forget. Also think about storing those keys on offline storage/computer - you can use those offline storage to sign transactions in the emergent cases when you'll need to access those wallets.
Related
I am collecting a payment using Stripe, and want to keep a portion, and send the rest onto another account from another organisation.
Stripe have told me that I have to connect an account. I have done this, Stripe gives me a link which the other organisation pastes into their browser, and all works. I can create a transfer linked to a payment intent.
But, when the link is pasted into the other organistions browser, this message is shown.
______ will be able to see your account data (such as all payment and payout history), including any data created by other business you've connected. They'll also be able to create new payments and take other actions for you.
This seems crazy - I just want to pay them some money, not ask them for full access.
Am I missing a trick?
Stripe Connect is a product/tool that allows accounts to work together to provide goods and services to end customers. There are a few different approaches to how this is configured based on your use case as well as whether you would be acting as the Platform (the one in control) or the Connect Account.
You should review the different Connect Account Types and determine what best matches your use case. Some questions to consider are as follows:
Who is interfacing with the end-customer (you or the other account)?
Who is providing the product/service?
Is this other account providing a service to you in exchange for a cut of the revenue?
On what account should the transactions and customers be stored?
It sounds like, based on the warning message, you were creating the other account to be the Platform and you would be Connect Account. In that cases the other account could make API calls on your behalf using your account token. This would be normal if the other account is providing a service to you like funneling customers to you in some way. A good way to quickly review what approach makes the most sense for your use case is to review the Funds Flow diagrams for the different types of Charges
Direct Charges
Destination Charges
Separate Charges and Transfers
I know how to transfer money from one account to another one but I need recommendation regarding the following scheme
Need to send 100$ to destination customer
90$ from client
10$ from platform
Is it possible?
Say I have a company where I want to make direct deposits to members' bank account. I understand that's it a really bad idea to ask them their information on the site and store it in the database.
But what If i ask our members to email us their bank info for direct deposits? I would then simply take their info and put it in excel sheet instead of storing it in the server(and delete the original email). That would be my reference point to sending the members direct deposits using my bank account. Is that legally allowed? If not, what would be another method to request a member's bank account info to make direct deposits?
Collecting banking account information has significant security implications and doing via email is not kosher. But there are alternatives.
The simplest alternative is using interbank service like Zelle where you can send money to your members' bank accounts using just their email accounts (the one associated with their bank login). We pay our smaller vendors this way and most get paid immediately without any transaction fees. But this may not work for members who use smaller banks outside the network (e.g credit unions) and the service does not have sophisticated tracking or linking to invoices.
If you have international members or need a more scalable/programmatic/self-serve solution, you can consider using a payment gateway provider like paypal/braintree or stripe-connect. Stripe is especially easy to integrate with a website and instead of you collecting and maintaining banking information for your members, stripe does on your behalf. Companies like Lyft use this to pay their drivers. It scales and works in almost all major international locations. Downside is there are per transaction fees which get steep if you want instant payments.
I'm working on a simple web service that allows users to sign up for free and upload a small amount of data. I can easily establish a quota for each user, but malicious users could create fake accounts to upload as much data as they like in a denial-of-service attack.
Obviously, there's no perfect defense against this type of attack, but what can we do to mitigate this problem?
Tie it to a more-or-less unique identifier (phone number, bank account number, facebook/google/etc account) or to a finite resource (such as time, by using a captcha).
use a captcha on account creation to ensure that it's a
human and not an automated process.
require a valid email address and require that they click a link in their email to validate that that's their email address and continue the registration process. This cuts down on their ability to create many throwaway accounts because you can limit them to only having one account per email address and they have to then create a new email address for each account they want to create.
When the user signs up, the user supplies a valid email. Most accounts are not enabled until a response has been received, usually by clicking a link in the body of that email. When that click-through is received, you should be able to grab an IP address. That should help you curtail an abundance of casual DOS attacks.
Consider Phone Number Verification
Requiring phone number for account creation is the best approach I've come across; Creating a new email or cycling an IP address is pretty trivial, but genuine sms phone numbers cost money to activate & grant your service the ability to restrict access by country-code.
An important caveat: Virtual phone numbers (like google-voice), temporary-phone number services, & burner phones can make sms-verification ineffective at preventing duplicate user accounts. Depending on your use case, it might be worthwhile to use a service, like Vonage's Number Insight api, that lets you identify those types of numbers.
Authillo is a passwordless authentication provider that prevents duplicate/fake accounts by leveraging sms verification, liveness detection, & facial recognition. Depending on how critical it is that you prevent fake accounts on your service, their base plan might be what you're looking for.
Just log the IPs and assume the same user if the IP does not change within a time interval. This is bad, because it would prevent multiple users in the same house (same IP) but it is a good start.
I'm building an app that needs to accept credit card payments with something like active merchant. In terms of security, is it possible for it to live on heroku and use authorize.net (or similar) as the payment gateway?
What if it needs to store the credit card numbers?
Edit
Would not be forwarding users to authorize.net.
The simple answer is yes, I believe so, but beyond that it depends.
You can set environment variables for various keys and other values related to the third party service(http://docs.heroku.com/config-vars), or just check them in and deploy them.
If you are using the hosted payment service for authorize.net, and forward to their site, you don't need ssl yourself. If you will be hosting the form where credit card number and personal info are submitted, then forwarding this to authorize.net via their API on the server, you need to set-up ssl for heroku (http://docs.heroku.com/ssl) so that your form is secure.
Now, it is one thing to accept payment via credit cards and just pass it thourgh, it is another to save credit card numbers and other private information. Without pointing you to various security standards docs (i.e. PCI DSS applies here), I will simply say that unless you absolutely have to, don't store CC numbers and related personal information, just forward to the gateway and make sure you aren't logging those fields (http://guides.rubyonrails.org/security.html#logging). If you do need to store credit card data, I think you need to have more control of the database and server to reach compliance, and I don't know a general cloud host like AWS or heroku that you can use and do this (maybe some other SO user will correct me). Using a payment gateway like authorize.net, however, can get you there.
I'll also point out that different states now have laws about storing sensitive data (like MA, where I live), so yet another reason to avoid doing it unless it is essential to your business model.
For a somewhat dated, but good general discussion of PCI compliance, look here: http://broadcast.oreilly.com/2009/02/pci-in-the-cloud.html