Preventing customers from hacking my MSDE database?

Recently I installed a commercial client-only product utilizing an
MSDE database.
The product installed its own instance of MSDE rather than adding a
database to the default instance (or install a default instance).
Of course, not with a blank sa password, so I could not access it
just by firing up Enterprise Manager or Query Analyzer.
Still, I was curious about the structure of the database, so
all I had to do to gain access to the table structure and data was to
stop the service for the MSDE instance, locate the database and log
files, copy them to another location, and attach them to the default
instance. I now had access to the table structure and all the data.
Still, the triggers and stored procedures were stored with encryption,
but this was no problem for a tool like Orbital's SQL Decryptor or a
couple of other scripts freely available on the Internet.
Question is: Is there anything the author could have done to prevent
me from doing any of the above? Or to put it another way: Is there
anything I can do to prevent others from accessing data in my own
programs in unauthorized ways?
TIA,
JBHave you tried to remove the user from System Admin server role and give
them an appropriate permissions?
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>|||Basically no. If it is installed on their server then most likely they will
have the ability to access your files and or the db directly. Your best
recourse is to have very good copywrite, NDA's etc. in place.
Andrew J. Kelly SQL MVP
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>