secure my DLL against use by others

[=?Utf-8?B?TWljaGVsQFZvb3JidXJn?=]

Hi all,

i've built a C# dll / component with some wonderful services to the clients
Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

I tried code access security, bu i can only use that on Class level and not
on Assembly level, and i've read that there are ways to work around this kind
of protection.

Do you have any other ways of assuring that my program will be the only one
using the DLL/assembly?

Regards,

Michel

[\(O\)enone]

Michel@Voorburg wrote:

i've built a C# dll / component with some wonderful services to the
clients Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

[...]

Do you have any other ways of assuring that my program will be the
only one using the DLL/assembly?

Unless I'm way off on how your system works, I think you're looking at
putting security in the wrong place.

Presumably your DLL performs updates to a database when its methods are
called. If one of the developers has access to update the database via your
DLL, then surely they have access to the database directly as well. Then
they could just modify the database to raise their salary, bypassing your
DLL entirely.

If you secure the database so that other people can't access it, then it
won't matter if they use your DLL as they won't be able to open a database
connection. Database engines have lots of functionality to facilitate
restricted access, unlike DLLs.

Does that help at all?

--

(O)enone

[=?Utf-8?B?RGVsdGEtTjogSGVybWFuIEdyZXZlbg==?=]

Thanks,

i think i wasn't clear enough on this one...
What i am afraid of is that someone reference my dll on the webserver
somehow..
So they don't have direct access to the webserver or database, but that they
can access the dll via some kind of share on the server...

Michel

"(O)enone" wrote:

Michel@Voorburg wrote:

i've built a C# dll / component with some wonderful services to the
clients Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

[...]

Do you have any other ways of assuring that my program will be the
only one using the DLL/assembly?

Unless I'm way off on how your system works, I think you're looking at
putting security in the wrong place.

Presumably your DLL performs updates to a database when its methods are
called. If one of the developers has access to update the database via your
DLL, then surely they have access to the database directly as well. Then
they could just modify the database to raise their salary, bypassing your
DLL entirely.

If you secure the database so that other people can't access it, then it
won't matter if they use your DLL as they won't be able to open a database
connection. Database engines have lots of functionality to facilitate
restricted access, unlike DLLs.

Does that help at all?

--

(O)enone

[Kevin Spencer]

A DLL is not an executable. It must be used by an executable. Therefore, if
the DLL accesses the database, it must use a Connection String which
provides the necessary credentials, or it uses Windows Authentication, in
which case it may access the database using the context of the user account
running the application. In either case, another application using the DLL
will not be able to access the database unless you've hard-coded a
Connection String with valid credentials into the DLL itself.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"Delta-N: Herman Greven" <De************ ****@discussion s.microsoft.com >
wrote in message news:52******** *************** ***********@mic rosoft.com...

Thanks,

i think i wasn't clear enough on this one...
What i am afraid of is that someone reference my dll on the webserver
somehow..
So they don't have direct access to the webserver or database, but that
they
can access the dll via some kind of share on the server...

Michel

"(O)enone" wrote:

>Michel@Voorbur g wrote:

i've built a C# dll / component with some wonderful services to the
clients Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

[...]

Do you have any other ways of assuring that my program will be the
only one using the DLL/assembly?

Unless I'm way off on how your system works, I think you're looking at
putting security in the wrong place.

Presumably your DLL performs updates to a database when its methods are
called. If one of the developers has access to update the database via
your
DLL, then surely they have access to the database directly as well. Then
they could just modify the database to raise their salary, bypassing your
DLL entirely.

If you secure the database so that other people can't access it, then it
won't matter if they use your DLL as they won't be able to open a
database
connection. Database engines have lots of functionality to facilitate
restricted access, unlike DLLs.

Does that help at all?

--

(O)enone

[=?Utf-8?B?TW9kZWxCdWlsZGVy?=]

If your DLL somehow bypasses the normal authentication procedures, then that
is something you should fix in your code. If the database does not have
strong authentication set up, then that should be fixed on the DB side. Your
code would then need to be setup appropriately. If the person has the
authentication information in hand, then there is not much left to protect.

"Delta-N: Herman Greven" wrote:

Thanks,

i think i wasn't clear enough on this one...
What i am afraid of is that someone reference my dll on the webserver
somehow..
So they don't have direct access to the webserver or database, but that they
can access the dll via some kind of share on the server...

Michel

"(O)enone" wrote:

Michel@Voorburg wrote:

i've built a C# dll / component with some wonderful services to the
clients Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

[...]

Do you have any other ways of assuring that my program will be the
only one using the DLL/assembly?

Unless I'm way off on how your system works, I think you're looking at
putting security in the wrong place.

Presumably your DLL performs updates to a database when its methods are
called. If one of the developers has access to update the database via your
DLL, then surely they have access to the database directly as well. Then
they could just modify the database to raise their salary, bypassing your
DLL entirely.

If you secure the database so that other people can't access it, then it
won't matter if they use your DLL as they won't be able to open a database
connection. Database engines have lots of functionality to facilitate
restricted access, unlike DLLs.

Does that help at all?

--

(O)enone

[John Vottero]

"Michel@Voorbur g" <Mi************ @discussions.mi crosoft.comwrot e in
message news:5E******** *************** ***********@mic rosoft.com...

Hi all,

i've built a C# dll / component with some wonderful services to the
clients
Payroll service.
As you might guess, i only want MY pogram to use this DLL.
If some developer get's hold of a reference to my dll, he or she could
easily use all methods to raise his or hers salary....

I tried code access security, bu i can only use that on Class level and
not
on Assembly level, and i've read that there are ways to work around this
kind
of protection.

Do you have any other ways of assuring that my program will be the only
one
using the DLL/assembly?

I agree with the other posters who have suggested that you might want to
look at DB security etc.

That being said, you can secure your DLL by making your public
classes/methods/properties internal and then using the InternalsVisibl eTo
attribute to expose internals to specific assemblies that are allowed to
call your dll. Those specific assemblies will have to have strong names.

Even that isn't very secure because you can still call private/internal
members via reflection and it's fairly easy to disassembly your dll, change
everything to public and rebuild. Securing your assembly like this is just
a way to keep people from calling things that may change in future versions
etc, if you really want security, it has to be in the database.