If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > how to protect the database from 3rd party clients ?

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old
Registered User
 
Join Date: Dec 2012
Posts: 3
Question how to protect the database from 3rd party clients ?

suppose you have a database application that connect to a database with 2 tables . in a certain operation the user should add a record in one table and add a corresponding record in the other table (otherwise the data integrity become -for example - incorrect ).
the question is : what prevent a user from using any 3rd party database client ,logging in from there (using their legit user names and password) adding the record to one of the table but not the other.
Reply With Quote
  #2 (permalink)  
Old
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 20,000
you said it yourself -- data integrity

do some research on foreign keys
__________________
rudy.ca | @rudydotca
Buy my SitePoint book: Simply SQL
Reply With Quote
  #3 (permalink)  
Old
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 14,774
Probably the simplest answer is "application authentication" where the application itself
  1. Logs into the database
  2. Authenticates the application user
  3. Controls what the user can/can't do
  4. Makes those changes on behalf of the user using the application's connection to the database
This way the user doesn't need any database login, but if you create one for them it can have different permissions than those that the application has.

-PatP
__________________
In theory, theory and practice are identical. In practice, theory and practice are unrelated.
Reply With Quote
  #4 (permalink)  
Old
Registered User
 
Join Date: Dec 2012
Posts: 3
Exclamation

Quote:
Originally Posted by Pat Phelan View Post
Probably the simplest answer is "application authentication" where the application itself
  1. Logs into the database
  2. Authenticates the application user
  3. Controls what the user can/can't do
  4. Makes those changes on behalf of the user using the application's connection to the database
This way the user doesn't need any database login, but if you create one for them it can have different permissions than those that the application has.

-PatP
what about reverse engineering ?
he could reverse engineer the program extracting the username / password needed to log into the database !!!
Reply With Quote
  #5 (permalink)  
Old
Registered User
 
Join Date: Oct 2009
Location: 221B Baker St.
Posts: 487
Quote:
he could reverse engineer the program extracting the username / password needed to log into the database !!!
I suspect not - if the design was proper . . .
Reply With Quote
  #6 (permalink)  
Old
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 14,774
If anyone can get to it, a sufficiently talented and dedicated professional can breach it. There is no such thing as absolute security for any application/database/whatnot that can be used. If you want data to be 100% secure, never store it!

Within reason, no one with the necessary talent will spend the necessary time to crack 99.99% of the systems in existance. Since it is FAR easier to use social engineering or a man-in-the-middle variant than brute force against almost every system that I've ever seen deployed, hard core "cracking" like what Jeorge Kabbi is describing is nearly un-necessary anymore.

-PatP
__________________
In theory, theory and practice are identical. In practice, theory and practice are unrelated.
Reply With Quote
  #7 (permalink)  
Old
Registered User
 
Join Date: Oct 2009
Location: 221B Baker St.
Posts: 487
Quote:
If you want data to be 100% secure, never store it!
I was once in a meeting with some rather big-wigs from the DoD and the discussion went on and on and on about how this data could be secured.

My cohort and i (invited to provide some technical perspective) had more than enough of this nonsense and he got the floor and offered "It could always be stored in a write-only file - one that no process or code could read". Unfortunately, the 2-star thought this was a fantastic idea (no IT guy this one). This was received with many grins and a few chuckles - until the 2-star realized he'd bit . . . Meeting ended not long after . . .

And no one died . . .

Last edited by papadi; 01-02-13 at 14:59.
Reply With Quote
  #8 (permalink)  
Old
Registered User
 
Join Date: Dec 2012
Posts: 3
Quote:
Originally Posted by Pat Phelan View Post
If you want data to be 100% secure, never store it!


-PatP
in 1998 i started learning visual basic 6 database programming as a hobby. i remember the possibility of using "stored procedure" to do stuff 100% server side. what about that ?
can we use stored procedure to do everything ? if so will the performance suffer ?
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On