4

In Database 101 you learned never to distribute the sensitive database password along with your program, since all a person has to do is reverse engineer the program, find where you actually need the original password for authentication, then echo/print that line. However when you have multiple remote programs that need to talk to a central database, what do you do?

My hackish solutions used to involve PHP, tons of GET variables, and JSON. I would make a request to the server with a set mode and parameters, then parse the JSON output. It was buggy, not entirely secure (only slowed an attacker down) since I didn't have any registration mechanism, hard to scale, and made all existing ORM's useless. Besides, it was attempting to reinvent SSH or SSL, not something that's too terribly smart.

What's the alternative though? What other options are out there that can provide security for the database while making it easy on me?

Chris
  • 5,663
  • 3
  • 28
  • 39
TheLQ
  • 13,478
  • 7
  • 55
  • 87
  • Not entirely sure what to tag this with besides `[database]`. `[remote-programs]` perhaps? – TheLQ Dec 15 '10 at 23:00
  • Distributed development seemed like an appropriate tag for this though that tag could also mean your development team is distributed. – Chris Dec 15 '10 at 23:01

2 Answers2

5

The biggest thing I can comment on with databases and applications is to have multiple accounts. Separate accounts for read and write access also and give these accounts the least required access to complete the given task.

You do have alternatives such as VPN's/SSH tunnels too have a more secure channel for distributed remote access to your central database.

Also, you should never really in your applications directly deal with the database, rather your applications should have a database abstraction layer or some sort which interacts with database. This is one: good design, and two: a better approach as you place all the DB interaction in one place and provide your application with an API to use the database interaction layer.

Chris
  • 5,663
  • 3
  • 28
  • 39
  • 1
    Creating multiple accounts doesn't help my fears much because the programs most likely need select, update, and insert, which is all an attacker needs. With the DB Abstraction Layer, I've made small ones before, but the task was always so daunting that I gave up. – TheLQ Dec 15 '10 at 23:09
  • If you are not concerned with performance entirely go the ORM route and encapsulate the ORM interactions into a simple class or layer that your applications will rely on. A professor of mine always suggested separating accounts for responsibility. The account for performing selects to retrieve data need not have delete/update/insert permissions. Same as delete or anything else. Large applications are a daunting task but if you want a rock solid design resilient to feature creep and providing flexibility to expand than you need to take on those daunting tasks. – Chris Dec 15 '10 at 23:11
  • 1
    Also, by encapsulating the ORM you can swap the database layer our down the road for your own, or another ORM. Not entirely easy to go ORM to another ORM but if you design your application correctly by abstracting these details out and placing them in one spot the change should not be too much maintenance merely development time to code. – Chris Dec 15 '10 at 23:12
4

Wrapping the database in a services/API layer is the most common way to do this.

At the most basic level provide full ORM mapping, but generally you would provide endpoints that provide different create / update / result features.

Like your hackish PHP solution, only good :)

ocodo
  • 2,948
  • 3
  • 23
  • 31