Serious Security Issues with a .DBC Conn. SQL2000 User and Pwd Issue

[tncf]

I have a serious security problem with VFP DBC and SQL 2000. I am tring to secure VFP8.0 remote views access to SQL. I use a SQLString in the connection within the DBC. I do not use ODBC.

Here is a sample of my SQLSTRING
DRIVER=SQL Server;SERVER=tnapp1;UID=sa;PWD=abc;APP=Microsoft Visual FoxPro;WSID=TNCF2;DATABASE=tn_crm

The problem is that anyone, from within Foxpro, can simply open a DBC and see the connection string settings to SQL..or anywhere!!!

Is there a way to lock a .DBC container with a password or create a 'true' secured DBC connection string information?

 

[Mike Lewis]

TNCF,

Was this the same question that you (or someone) posted yesterday?

To summarise the answers to that question (as far as I remember them):

- Forget about "locking" or encrypting the DBC.

- Ideally, don't use the DBC to hold the connection object. Instead, use SQLSTRINGCONNECT() to connect to the server. Create the connection string programmatically, passing it to SQLSTRINGCONNECT().

- If you must use the connection object in the DBC, leave the login and password blank in the designer. The server will display a login dialogue at run time. The disadvantage of this approach is that you have no control over what happens if the login is rejected or the user cancels the dialogue.

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[tncf]

Hello Mike. Yes I did post it, but in another forum. I received an e-mail from someone suggesting that I posted it here instead. Oddly, I can't find my original posting. Anyway..

I looks like information saved within a DBC can't be secured. I guess I should have used SQL passthrough from the beginning..

The problem being is that to do this, I would have to change over 150 views to an application used by 1,800 users, distributed over 15 servers!..hardly a simple task..

I guess these are the limitation that make you wonder where VFP is really going. From my part, I really don't code anymore, but I did select the initial VFP for most of the applications developed in my company. You see, I own the 2nd largest consulting company in the Caribbean, employing over 85 consultants, developers, engineers, etc. In terms of coding..I am old school, as they say..I do see every day a bunch of great young developers coming up with .Net intereset and others. Makes you wonder if I should switch..(not me!! the company...

Anyway, thank for your response..CF

 

[Mike Lewis]

I looks like information saved within a DBC can't be secured. I guess I should have used SQL passthrough from the beginning..

Well, SPT does give you a lot more flexibility, and that includes the ability to specify login details dynamically. But there are ways of using remote views securely as well. For example, you could programmatically create a temporary copy of the DBC on the user's hard drive and delete it when the session ends. That's not completely secure, of course, but it's a lot better than users sharing a connection object.

I guess these are the limitation that make you wonder where VFP is really going.

I have to disagree with that. In all programming languages, there are trade offs. In this case, it's simply a choice between the convenience of remote views vs. the flexibility of SQL pass-through. It's not a limitation of the language, and I also disagree that this is a "serious security issue" as the title of your thread suggests.

If you switched to a different platform, you might find this issue doesn't exist, but I'll bet there'll be other trade-offs to worry about.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[baltman]

Perhaps you can adapt this FAQ for your needs. Protect your apps/functions with a dll faq184-4964

Brian

 

[rkolva]

Could you use a 3rd party tool like Cryptor? You could encrypt the DBC so that it couldn't be opened outside of your applications. I've used Cryptor in some of our apps and it's pretty easy to roll into an application. The package we originally purchased came with 100 run time licenses and the unlimited run time license wasn't that expensive. I like that Crytor decrypts in memory, not the file system, so that if the app or machine inadvertantly dies you're not left with unprotected files.

If you use Brian's suggestion I would recommend you don't name the password file anything that suggests what it contains. Even though it's being checked in a DLL any text editor can be used to read DLL and see the plainly visible 'pass.txt' referenced file and then do a file search for the password. Granted a casual user wouldn't think of this but then again it seems you're concerned with users opening a DBC file. I would think if that's an issue then perhaps looking for a text based password file might be within their skills.

Ralph Kolva