We are trying to secure a SQL Anywhere (v17) database used by our application.

Ideally we want all access to the database to be through our application only. Currently its quite easy to discover the username/password used by our applications ODBC connection to the database.

What options do we have to further secure our database and stop any connections that don't originate from our application?

We have considered using the login_procedure option to write logic to only accept connections from our applications full path / filename taken from AppInfo, and applying this to all connections. The general idea stems from this post.

Would this be enough, or is there some way this could be bypassed? (without our users renaming their application and moving it into the approved path - we aren't concerned about this scenario as it is unlikely given how heavily used our application is).

Are there better solutions to locking down the database, given that our application is currently dependant on one username/password which has access to most tables? (We understand this itself isn't ideal - but changing it would require a lot of redevelopment)

We would appreciate any insights

asked 05 Jan, 18:24

grandev's gravatar image

grandev
263
accept rate: 0%


There are quite a few potential approaches, apart from Volker's route, you could also consider using SQLAnywhere's communication encryption options.

You would set the server only to accept encrypted communications (-ec TLS etc). Then you use the ENP (encoded password) connection parameter to pass the password with the ODBC connection string. You can encode the password so it is locked to a specific user and machine. See the docs here

permanent link

answered 06 Jan, 13:01

Justin%20Willey's gravatar image

Justin Willey
7.5k136177247
accept rate: 19%

edited 06 Jan, 13:09

1

For our products, where we face some of the some of the same issues as you, we use a slightly different approach. We don't store the connection details in the registry, but create them on the fly from the application as is connects. Each customer has their own encryption key which is stored locally but strongly encrypted itself. Only the application can decrpyt the key and it then uses it to make the connection. The database itself and the communications are strongly encrypted with the key.

As with everything, someone with enough information and enough access could attempt to break in, but there are a lot of obstacles in their way, and every database presents a separate challenge.

(06 Jan, 13:08) Justin Willey

We tried several security protocols, but every one can be read when making a memory dump at the right moment. Somehow it's just to difficult to really encrypt the connection correctly both while stored and while being used. You could better create events or whatever to drop 'illegal' connections or force a reply from your application on a message from the database server. Obfuscate who/what is blocking 'permanent' connections and make sure there are not many rights given so a connection cannot create new users nor drop any procedures.

(16 Jan, 02:17) ArcoW
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×219
×47

question asked: 05 Jan, 18:24

question was seen: 180 times

last updated: 16 Jan, 02:17