There is a website with a server database. I'm building a desktop application which uses data from one of the tables. Hacker can just take password from assembly.
How can I protect the database?
+13
A:
I wouldn't store the database information in the application at all. Instead, I would create an API to the database on the website, perhaps implementing a RESTful interface or having queries that return data in an appropriate format, such as JSON, XML, or even plain text. The application could then call these web services and process the results. All of your database information stays on the server, where it is (hopefully) secure.
Thomas Owens
2009-11-07 18:09:44
How all that garbage can protect the database? What is necessary is: proper access control, profuse use of integrity constraints and views for fine-grain security (capability-based security). I can think of only one reason to sandbox a DBMS implementation: it sucks and can be fooled tinkering with its communication protocol. But even in such case I don't see what a redundant textual protocol can contribute, since the network is probably the bottleneck.
MaD70
2009-11-08 00:17:20
This "garbage" can protect the database because you can limit the access that the user has to the content without risking security. In all cases, this might not be the optimal solution, but it is definitely one that I would consider.
Thomas Owens
2009-11-08 06:52:54
I'm puzzled. Have you read something of my comment, beyond the first sentence?
MaD70
2009-11-08 12:50:17
The rest of it is incorrect. Lots of people sandbox their databases, and they should. It's just the right thing to do.
Thomas Owens
2009-11-08 18:51:16
Thank you for this profound technical enlightenment, " *Thus Do They All* "... I hope you will be not offended if I prefer Mozart (or Tinto Brass).
MaD70
2009-11-09 20:06:51
More seriously: the false sense of security induced by this mythology around text-based protocols resulted in SQL code injection. What I'm saying is: "is it not time to ask DBMSes producers robust and secure protocols to communicate with their DBMSes?"
MaD70
2009-11-10 13:23:34
The rest (access control, integrity constraints, views for capability-based security) is about "semantics safety" and is absolutely relevant, contrary to what "lots of people" think these days.
MaD70
2009-11-10 13:32:25
A:
Don't let the database user the application logs in as perform any write operations or read operations on anything but the application data.
Or, choose a sane architecture, as Thomas mentions above. Databases are for storing and retrieving data, they are not a generic application server.
jrockway
2009-11-07 18:20:58
+1
A:
The API adds a sometimes unnecessary application layer. Not all applications i've been involved with easily convert from using database calls to webservice calls. If the application has not been written i guess it would not matter that much.
My alternative implementation is:
- Connect to the server using a secure tunnel of some sort.
- Save the password encrypted on disk.
This would save me the effort of creating an API, which in most of my projects would be a waste of time.
This alternative is not viable if let's say you want to distribute the application to customers.
Peter Lindqvist
2009-11-07 19:57:29
+1
A:
Your can
A) create a three tier system. Your client could interface with a server that in turn interfaces with the database. The server stores the access credentials.
B) create personal accounts on the database for your users. This two tier model is applicable if fine grained access control to data is needed. E.g. in an inhouse application with different user roles.
Niels Castle
2009-11-07 21:36:47