.NET Security: Store PKs in C++ DLL?

[keitsi]

Hi. I am aware of the matter that you can decompile IL code back to very readable C#/VB.NET.

 

After a though I don't give a crap if someone takes a peek at the source code, because probably he could do it in the same time by writing a new one from scratch. Also understanding and being able to alter the code in a working fashion would require some time.

 

I am more concerned about storing DB passwords and Private Keys.

 

At the moment it happens this way:

- SQL password is in seperate config file crypted with 3DES (192)

- Private Key and IV used by 3DES are hardcoded in binary file (the main EXE in IL)

 

Ok, when the applicaiton starts, password required by SQL server is decrypted from the encrypted password. Even if I store the PK in seperate C++ DLL, you could easily retrieve it by:

- attaching a debugger to the running project (right?)

- decompiling the IL and finding the entrypoint name used to retrieve PK

 

Anyone know of a secure enough way to do this? I am not concerned about someone using assebler to retrieve the PK since that would require significantly bigger effort, and that would be possible even if the application was fully written in C++. Obfuscating the IL code probably wouldn't help much since I'm not concerned about someone looking at the source; PKs are the most important matter.

 

The program is written in VB.NET and some modules in C#. Program uses ByteFX's MySqlClient (written in C#) for MySQL communication. Making it hard for someone to crack the SQL password would be very neat.

 

I have some C++ exprience and I think writing a C++ DLL would not be big effort. Thanks in advance if someone is able to guide me a bit. What methods would you recommend?

Edited July 21, 2004 by keitsi

[Denaes]

Based on what I've read, one of the main purposes of Dotfuscating your code is if you have passwords. Apparently it reduces your precompiled IL into jibberish, and gives you a slight performance boost.

 

This is the jist of what I got from a few .Net books. I don't have any experience using Dotfuscator or anything.

[Nerseus]

One solution is to not use direct connections from a client. This is one of the benefits of an n-tier architecture. A webserver typically takes the credentials, verifies the user, then lets them in (assigning them a session ID or cookie or similar token). On subsequent calls, only this auto-generated token is passed. On every call it's validated and, if it works, the user gets access to the webmethod which handles DB connection strings and such and returns the data.

 

If you're in a client/server architecture and can't use the webserver (or any remote server), then I've seen the following approach used with success:

A user enters their uid/pwd and logs into a "test" database. The app uses a special login "testuser/password" to get access to the test database and verifies their credentials. This will the return, encrypted, the userid and password to the client machine "on the fly" so that it is never stored (except in memory). A similar approach had this functionality compiled into a COM object that exposed the connection objects to the main app.

 

There are a number of "better" solutions, most just take more administrative work. You could force all users to get their own credentials and log into a database using SQL Server's credentials (not trusted connections). Their userIDs would not have any direct table access. They would only be granted rights to the procs. You could also do this with a single userid/password that everyone shares.

 

-ner

[Joe Mamma]

SQL 2000 C2 Admin and User Guide

 

C2 is an NSA specification for implementing security in applications.

This guide describes how to set up a SQL server that will be meet NSA C2 qualifications.

 

SQL Server 2000 SP3 Security Features and Best Practices is a great guide, too. Specifically SQL Server 2000 SP3 Security Features and Best Practices: Secure Multi-tier Deployment

 

while this is a guideline for MS SQL server applications, its techniques are universal.

[keitsi]

One solution is to not use direct connections from a client. This is one of the benefits of an n-tier architecture. A webserver typically takes the credentials, verifies the user, then lets them in (assigning them a session ID or cookie or similar token). On subsequent calls, only this auto-generated token is passed. On every call it's validated and, if it works, the user gets access to the webmethod which handles DB connection strings and such and returns the data.

Tbh we though of something like that when we started to design the system - we came in to conclusion that it would have been too complex to implement in the given time. The fact that you can decompile .NET IL _SO_ easily came in to knownledge later, this was also another reason why we didn't design it to be a "dumb client viewer" with server-side permission checks.

 

I've seen the following approach used with success:

A user enters their uid/pwd and logs into a "test" database. The app uses a special login "testuser/password" to get access to the test database and verifies their credentials. This will the return, encrypted, the userid and password to the client machine "on the fly" so that it is never stored (except in memory). A similar approach had this functionality compiled into a COM object that exposed the connection objects to the main app.

Sounds fair enough - didn't even think of a solution like that.

 

Let me get it straight:

- you login to the authentication DB using some default username and password, which could be stored for example in C++ DLL

- once connected to SQL, you select the "real", encrypted username and password from some table, which are same for every user (?)

- you decrypt the retrieved login & pass (maybe this could also be done calling a C++ DLL) and login to the "real" DB

 

Damn I'm tired, not sure if I got it all right :)

..sounds good anyway. In the other hand, what's the point in C++ DLL calls if you can discover the entrypoint name in 30 seconds.

 

There are a number of "better" solutions, most just take more administrative work. You could force all users to get their own credentials and log into a database using SQL Server's credentials (not trusted connections). Their userIDs would not have any direct table access. They would only be granted rights to the procs. You could also do this with a single userid/password that everyone shares.

For now, I will be satisfied with "somewhat" secure solution. Most likely the people using this application won't know much of programming. If hacking the login&password is even somewhat complicated, there probably (hopefully) won't be any hackings ;)

 

I already implemented a "hidden" C++ DLL call, with a pointer to byte[] Key, which manipulates the hardcoded crypt key a bit. The method lyes "camouflaged" with other unrelevant code and is called when application is started. Maybe by filling the app with stuff like this will make it frustrating enough to prevent potential hackers from bothering. Hehe, am I pathetic enough? I guess committed C++ coders would make a good laugh of this :P

 

I'm kind of disappointed in .NET in this matter. :(

 

Well thanks for the answers, hopefully I figure this out.

Edited July 22, 2004 by keitsi