5 ms·

Yeah, I understand your concern. Bitcoinica has several features/characteristics that make itself like no other: - There's no Bitcoin wallet. Most incidents ha

Yeah, I understand your concern. Bitcoinica has several features/characteristics that make itself like no other: - There's no Bitcoin wallet. Most incidents happen with stolen or lost wallets. Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox). - Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc) - No account minimums. If you're unsure, you can deposit $1 first and try to do some trades. - Margin trading. This reduces risks. You don't have to deposit 100 BTC worth of USD when you want to long/short a 100 BTC position. 20 BTC is enough. Only when you lose a lot, you can consider adding more margin. I think trust is a common problem for all websites like Bitcoinica. That's why we designed the platform in the way that attempts to solve the fundamental problems. There's instant deposit and withdrawal too. You can transfer money from Mt. Gox when you want to trade and transfer it back after you close your position. (Assume that you trust Mt. Gox.)

michael_dorfman 15y ago
Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc) Uh-oh. Ruby on Rails has a lot of default settings that are decidedly not secure; our own Patio11 wrote an article on this topic for the CACM not too long ago. You might want to sit down with a security professional before too long, and get an outside opinion on your code.
- zhoutong 15y ago
  Currently our only non-trivial security challenges are as follows: - SQL Injection - Source being viewed - Financial attacks I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord. Heroku protects everything nicely. Even the filesystem is read-only. There's virtually no way to control the server provided Heroku's 3-layer architecture (Varnish, Nginx and Thin). We don't operate a Bitcoin wallet. Basically hackers have nothing to steal. Even if we are totally owned, the most that hackers can do is to get some free money and make some trades. After all, we can obviously identify and not to approve withdrawals (for unusual and large-amount ones).
  - acangiano 15y ago
    > I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord. Used properly, it's safe, but you can still screw up with ActiveRecord. For example: User.where("name = '#{params[:name]}') That's vulnerable to an SQL injection. You can make it safe, by using something like: User.find_by_name(params[:name]) Or if you want to stick with the where clause, one out of many ways of doing it, is: User.where(:name => params[:name])
    - zhoutong 15y ago
      Yeah, I understand your point. I have never ever used #{} in my code. When I first learned Rails, I know this should be avoided at all cost. I would prefer "String 1: " + string1 rather than "String 1: #{string1}"
      - bhousel 15y ago
        > Yeah, I understand your point. No, you don't...
      - bdonlan 15y ago
        Those two examples are _exactly_ the same; it's clear you don't understand the actual problem. With SQL, you must never, EVER mix untrusted data (ie, data from a user) with your trusted code (ie, SQL statements). The same applies to HTML - never, EVER mix untrusted data with trusted code (ie, HTML tags). If you want to mix the two, you must either: a) first take steps to make your untrusted data trustworthy - for HTML, use an appropriate HTML scrubbing library to remove dangerous tags (or simply escape every & or <). For SQL, you'd have to escape all metacharacters - but I wouldn't recommend doing this for SQL, see below b) Find a way to transfer the data separately. All modern SQL libraries allow you to specify named variables in your SQL code, then fill in the variables separately. With this, the SQL library takes care of separating the untrusted data and trusted code. The mechanism used to combine code and data is not the problem - + and #{} are equally harmful if used improperly, and equally harmless if properly escaped .
- patio11 15y ago
  My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business.
rmc 15y ago
Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox). Sounds like you've outsourced security to a website (Mt. Gox) that has a proven track record of being stupid with security. That does not reflect well on you.
- rheide 15y ago
  I think he's outsourced security to a site that has experience in dealing with security and has (hopefully) learned something from their mistakes. For bootstrapping, I'd say it's acceptable.

michael_dorfman 15y ago

Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc) Uh-oh. Ruby on Rails has a lot of default settings that are decidedly not secure; our own Patio11 wrote an article on this topic for the CACM not too long ago. You might want to sit down with a security professional before too long, and get an outside opinion on your code.

zhoutong 15y ago
Currently our only non-trivial security challenges are as follows: - SQL Injection - Source being viewed - Financial attacks I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord. Heroku protects everything nicely. Even the filesystem is read-only. There's virtually no way to control the server provided Heroku's 3-layer architecture (Varnish, Nginx and Thin). We don't operate a Bitcoin wallet. Basically hackers have nothing to steal. Even if we are totally owned, the most that hackers can do is to get some free money and make some trades. After all, we can obviously identify and not to approve withdrawals (for unusual and large-amount ones).
- acangiano 15y ago
  > I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord. Used properly, it's safe, but you can still screw up with ActiveRecord. For example: User.where("name = '#{params[:name]}') That's vulnerable to an SQL injection. You can make it safe, by using something like: User.find_by_name(params[:name]) Or if you want to stick with the where clause, one out of many ways of doing it, is: User.where(:name => params[:name])
  - zhoutong 15y ago
    Yeah, I understand your point. I have never ever used #{} in my code. When I first learned Rails, I know this should be avoided at all cost. I would prefer "String 1: " + string1 rather than "String 1: #{string1}"
    - bhousel 15y ago
      > Yeah, I understand your point. No, you don't...
    - bdonlan 15y ago
      Those two examples are _exactly_ the same; it's clear you don't understand the actual problem. With SQL, you must never, EVER mix untrusted data (ie, data from a user) with your trusted code (ie, SQL statements). The same applies to HTML - never, EVER mix untrusted data with trusted code (ie, HTML tags). If you want to mix the two, you must either: a) first take steps to make your untrusted data trustworthy - for HTML, use an appropriate HTML scrubbing library to remove dangerous tags (or simply escape every & or <). For SQL, you'd have to escape all metacharacters - but I wouldn't recommend doing this for SQL, see below b) Find a way to transfer the data separately. All modern SQL libraries allow you to specify named variables in your SQL code, then fill in the variables separately. With this, the SQL library takes care of separating the untrusted data and trusted code. The mechanism used to combine code and data is not the problem - + and #{} are equally harmful if used improperly, and equally harmless if properly escaped .
patio11 15y ago
My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business.

rmc 15y ago

Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox). Sounds like you've outsourced security to a website (Mt. Gox) that has a proven track record of being stupid with security. That does not reflect well on you.

rheide 15y ago
I think he's outsourced security to a site that has experience in dealing with security and has (hopefully) learned something from their mistakes. For bootstrapping, I'd say it's acceptable.