Quote from: neha on September 26, 2014, 12:38:43 PM

Quote from: LuaPod on September 26, 2014, 12:13:59 PM

Quote from: neha on September 26, 2014, 11:00:02 AM

Quote from: LuaPod on September 26, 2014, 10:31:37 AM

If I wanted to I could have my computer running a VPS with 13 GB of ram aloted and close all ports with outbound requests only. I could then use that Virtual machine to run the wallets. No ports being forwarded or any direct communications from anything. The servers decide their job based off of the Mysql Database they are connected to through a virtual network that is hub and spoke managed.

Its actually a little more complicated because if your webserver has access to the MYSQL db, then I could hypothetically just go and make changes in Mysql and take all your funds. You need to think how to ensure that even if I get access to the Mysql DB connected to the webserver, I shouldn't be able to cause any damage financially.

How could you make changes with a SQL user that has no write access to any of the finance tables nor any direct access to methods manipulating balances? If you were to read the description on the front page it clearly states that the SQL gives no permissions to the front-end except to view user information and to view balance information. IT can submit a request to be processed by the back end server that is structured like
create/trade/5/1000/100/5 and is signed and encrypted. Even if you managed to figure out the signing and encryption the backend servers do another check to verify the trade is even allowed to be created.

The servers all are on a closed network with communication enabled ONLY to the SQL database. Each server has its own SQL user with its own permission.

To even prove that you lacked the true effort of reading here is an excerpt from the main page:

Code:

[The webserver must only be capable of reading information and relaying commands without having any
direct access or direct command of the wallets. Any transactions believed to be taking place on the website are
in fact not taking place on the website. The users input is checked and their balances verified; Then the
system puts forth a structured request that is then processed by the Wallets server.]

Trust me I read but the fact is that if there is no way to write something in a db, then how will the user modify data. You cannot expect to provide manual intervention to each and every data entry. Again, if someone hacks the server, the purpose wont be to perform trades but to perform withdrawals. How have you designed your system so that you know for sure that the incoming request is true and is also automated.

Also, for this argument, assume that I have hacked the webserver and I exactly know your db username and password and even if the db server is on an internal network, I can still access it using the webserver ssh. Moreover, most probably if I have SSH access to the webserver, I will exactly know your DB encryption passwords.

I will give you the username and password for the DB right now

Mysql_User = "front-end"
Mysql_Pass = "m1taLu4ayu84vO7eVu27JOw1vIk7mo"
Mysql_Host = "25.15.147.88"

DNS NAME
luapod-sql.cloudapp.net
HOST NAME
LuaPod-Sql
PUBLIC VIRTUAL IP (VIP) ADDRESS
191.238.226.47

There you go. I already thought of the things you have said. The system is secure enough that I can give a hacker the mysql information and they would be incapable of financially harming me NOR revealing private user information other than email addresses.

The funny thing is you still couldn't get access to the database.

Also, the database isn't encrypted. The signature and hash passwords are entered upon each server boot. You would have to intercept me trying to boot the software. But good luck getting past the subversion code control with code signing.