Encrypting Database ?? vb3 - new user
| Author |
Message |
|
Mike Den
#1 / 6
|
 Encrypting Database ?? vb3 - new user I want to encyrpt a database so avoiding the user from changing data in access etc. Can anyone tell me how to do this ?? The code I have been experimenting on is as follows :-
Sub encrypt ()
DB_LANG_GENERAL = ";LANGID=0x0809;CP=1252;COUNTRY=0"
' CreateDatabase and CompactDatabase options
DB_VERSION10 = 1 ' Microsoft Access Version 1.0
DB_ENCRYPT = 2 ' Make database encrypted.
DB_DECRYPT = 4 ' Decrypt database while compacting.
'Main Stock File
start.dtaStock.DatabaseName = ""
start.dtaStock.Refresh
CompactDatabase "c:\stock\stock.mdb","c\stock\stock1.mdb",DB_LANG_GENERAL,
DB_ENCRYPT
Kill "c:\stock\stock.mdb"
Name "c:\stock\stock1.mdb" As "c:\stock\stock.mdb"
End Sub
It doesnt error but I can still open the database and make changes !!
If you can help me please email me on :-
many thanks
Mike
|
| Wed, 05 Jun 2002 03:00:00 GMT |
|
 |
|
Vinnie M
#2 / 6
|
Encrypting Database ?? vb3 - new user Mike, How about just putting a password on the database, so that only your
application can open it? If the user tries to open it in Access, it will
prompt for the password, stopping the user before they can get access to the
data.
--
Vinnie Murdico
Software with Brains, Inc.
Visual Basic Controls and Components
SWBTracker - Value-Priced Bug Tracking Software
http://www.softwarewithbrains.com
Quote: > I want to encyrpt a database so avoiding the user from changing data in > access etc. Can anyone tell me how to do this ?? > The code I have been experimenting on is as follows :-
> Sub encrypt ()
> DB_LANG_GENERAL = ";LANGID=0x0809;CP=1252;COUNTRY=0"
> ' CreateDatabase and CompactDatabase options
> DB_VERSION10 = 1 ' Microsoft Access Version 1.0
> DB_ENCRYPT = 2 ' Make database encrypted.
> DB_DECRYPT = 4 ' Decrypt database while compacting.
> 'Main Stock File
> start.dtaStock.DatabaseName = ""
> start.dtaStock.Refresh
> CompactDatabase "c:\stock\stock.mdb","c\stock\stock1.mdb",DB_LANG_GENERAL,
> DB_ENCRYPT
> Kill "c:\stock\stock.mdb"
> Name "c:\stock\stock1.mdb" As "c:\stock\stock.mdb"
> End Sub
> It doesnt error but I can still open the database and make changes !!
> If you can help me please email me on :-
> many thanks
> Mike
|
| Thu, 06 Jun 2002 03:00:00 GMT |
|
|
|
Peter Quic
#3 / 6
|
Encrypting Database ?? vb3 - new user Vinnie, When there are tools on the net which can retrieve an Access password in a
few seconds, costing a 30$, I don't call it secure !!!!!
Password protection is good for in-house products, not for distributing an
app containing secure data.
Just my 2 cents!
Pete
Quote: > Mike, > How about just putting a password on the database, so that only your
> application can open it? If the user tries to open it in Access, it will
> prompt for the password, stopping the user before they can get access to
the
> data.
> --
> Vinnie Murdico
> Software with Brains, Inc.
> Visual Basic Controls and Components
> SWBTracker - Value-Priced Bug Tracking Software
> http://www.softwarewithbrains.com
|
| Fri, 07 Jun 2002 03:00:00 GMT |
|
|
|
Vinnie M
#4 / 6
|
Encrypting Database ?? vb3 - new user Hi Pete, Agreed. If I were shipping an Access-based financial package for large
corporations and it was available for purchase by the general public, I
would not expect an Access password to secure it.
However, in several consulting projects I've worked on, the product was
designed not to be "secure against malicious hacking", but rather to be
secured so "wandering eyes" (curious employees within the company) don't
"mess up" any data in the database. The data was confidential, but did not
contain personal information of a financial nature. Of course, all personal
information is considered confidential, but I think there are degrees. On
the projects I worked on, the customers said they simply wanted to make sure
no one "accidentally" screwed up the database by messing around in Access.
They didn't necessarily want the information exposed, but they also didn't
see the need for an extensive encryption layer in the code to secure the
data against hackers.
Perhaps the original poster does need some type of "ultra-secure" method of
protecting the database, but perhaps he only needs to keep people from
making "accidental changes". Or perhaps his customer is someone that would
never dream of going out and spending the time searching the web for a
password hack just to be able to view the database. In the case of my
clients, they were way too busy at their jobs and didn't have time or desire
to hack into the database and locate confidential information. They simply
wanted a tool to store and retrieve data with a usable interface.
I guess we would need more information from the original poster. However,
I do think that in certain cases, a password is a quick, inexpensive
solution that solves the need desired by the user. It truly depends on the
requirements of the individual case. But I would agree that if your intent
is to secure the data from "intentional hacking", then an Access password
won't cut it.
Another interesting point this discussion raises is the ability to make the
product's data open and available. Having an "open architecture" database
is desirable by many product buyers because they can now write their own
reports and queries against the data. The desire for this type of read-only
access must be accounted for when implementing some type of encryption on
the database itself. If the data is encrypted inside the DB, the user won't
even be able to write reports or queries to access the data in a read-only
fashion without some intermediate process to extract and decrypt it. I
think all these factors should come into play when the designer tries to
protect a database from the customer. In fact, I used to work for a company
that produced an accounting package using an Access back end. And, as a
matter of fact, it was more important to their client base that they have
unlimited access to the data through external applications (Crystal Reports,
etc) than it was to have it encrypted, and so the decided method was an
Access password - nothing more. The only thing that was encrypted was user
ID's and passwords I guess they feel their user base simply isn't
interested in hacking the database, and I'd agree (knowing the demographics
of their customer base).
--
Vinnie Murdico
Software with Brains, Inc.
Visual Basic Controls and Components
SWBTracker - Value-Priced Bug Tracking Software
http://www.softwarewithbrains.com
Quote: > Vinnie, > When there are tools on the net which can retrieve an Access password in a
> few seconds, costing a 30$, I don't call it secure !!!!!
> Password protection is good for in-house products, not for distributing an
> app containing secure data.
> Just my 2 cents!
> Pete
> > Mike,
> > How about just putting a password on the database, so that only your
> > application can open it? If the user tries to open it in Access, it
will
> > prompt for the password, stopping the user before they can get access to
> the
> > data.
> > --
> > Vinnie Murdico
> > Software with Brains, Inc.
> > Visual Basic Controls and Components
> > SWBTracker - Value-Priced Bug Tracking Software
> > http://www.softwarewithbrains.com
|
| Sat, 08 Jun 2002 03:00:00 GMT |
|
|
|
Mike Den
#5 / 6
|
Encrypting Database ?? vb3 - new user Yes Vinnie you have hit the nail on the head... I dont want A super secure program just one that the normal user wont
accidentely dbl click the database and{*filter*}it up !!!
You say to password protect it using access ?
How do you then use this password protection in visual basic to allow access
??
may sound stupid to you but I am a beginner !!!
Many thanks
Mike
P.S - Any chance of emailing me with any answers as I am going away for a
couple of weeks !!
Quote:
>Hi Pete, >Agreed. If I were shipping an Access-based financial package for large
>corporations and it was available for purchase by the general public, I
>would not expect an Access password to secure it.
>However, in several consulting projects I've worked on, the product was
>designed not to be "secure against malicious hacking", but rather to be
>secured so "wandering eyes" (curious employees within the company) don't
>"mess up" any data in the database. The data was confidential, but did not
>contain personal information of a financial nature. Of course, all
personal
>information is considered confidential, but I think there are degrees. On
>the projects I worked on, the customers said they simply wanted to make
sure
>no one "accidentally" screwed up the database by messing around in Access.
>They didn't necessarily want the information exposed, but they also didn't
>see the need for an extensive encryption layer in the code to secure the
>data against hackers.
>Perhaps the original poster does need some type of "ultra-secure" method of
>protecting the database, but perhaps he only needs to keep people from
>making "accidental changes". Or perhaps his customer is someone that would
>never dream of going out and spending the time searching the web for a
>password hack just to be able to view the database. In the case of my
>clients, they were way too busy at their jobs and didn't have time or
desire
>to hack into the database and locate confidential information. They simply
>wanted a tool to store and retrieve data with a usable interface.
>I guess we would need more information from the original poster. However,
>I do think that in certain cases, a password is a quick, inexpensive
>solution that solves the need desired by the user. It truly depends on the
>requirements of the individual case. But I would agree that if your intent
>is to secure the data from "intentional hacking", then an Access password
>won't cut it.
>Another interesting point this discussion raises is the ability to make the
>product's data open and available. Having an "open architecture" database
>is desirable by many product buyers because they can now write their own
>reports and queries against the data. The desire for this type of
read-only
>access must be accounted for when implementing some type of encryption on
>the database itself. If the data is encrypted inside the DB, the user
won't
>even be able to write reports or queries to access the data in a read-only
>fashion without some intermediate process to extract and decrypt it. I
>think all these factors should come into play when the designer tries to
>protect a database from the customer. In fact, I used to work for a
company
>that produced an accounting package using an Access back end. And, as a
>matter of fact, it was more important to their client base that they have
>unlimited access to the data through external applications (Crystal
Reports,
>etc) than it was to have it encrypted, and so the decided method was an
>Access password - nothing more. The only thing that was encrypted was user
>ID's and passwords I guess they feel their user base simply isn't
>interested in hacking the database, and I'd agree (knowing the demographics
>of their customer base).
>--
>Vinnie Murdico
>Software with Brains, Inc.
>Visual Basic Controls and Components
>SWBTracker - Value-Priced Bug Tracking Software
> http://www.*-*-*.com/
|
| Sun, 09 Jun 2002 03:00:00 GMT |
|
|
|
Vinnie M
#6 / 6
|
Encrypting Database ?? vb3 - new user Hello Mike, Hey, everyone is a beginner at some point! No need to think any question
is stupid -- you have to learn somehow!
Actually, using a password-protected Access database from VB is easy.
Once you have set the password (which I guess you could do directly within
Access), you can then use code as follows:
gDBConnectString = ";pwd=test"
Set dbMyDB = OpenDatabase(sDBPath, False, False, gDBConnectString)
gDBConnectString is declared as a String type, and sDBPath is just a string
set to the path/name of the database file (.mdb). One important note is to
make sure you include the semicolon ( ; ) before the "pwd" in the connect
string, as shown above. You will, of course, substitute your DB's password
where "test" is included in the connect string above. This will allow the
code to open the database with your password and work with it normally.
while stopping external apps from opening it.
If you want to be able to work with the database at design time by setting
data controls and selecting table names in the data control's properties,
then you might want to set the data control's Connect property to the same
string as you are setting gDBConnectString above. That will allow VB's IDE
to open the MDB at design time so the design time controls (like the data
control) can have access to the table names, etc. This is helpful if you
set a data control to use this database, and want to use the pull down menu
for the Recordset property which will show a list of tables. It can't show
the list of tables if it can't open the DB. And it can't open the DB unless
the data control's Connect property has the correct password set at design
time. If you aren't using data controls, you don't need to worry about
this. The two lines of code above will work fine at run time.
Hope this helps.
--
Vinnie Murdico
Software with Brains, Inc.
Visual Basic Controls and Components
SWBTracker - Value-Priced Bug Tracking Software
http://www.*-*-*.com/
Quote: > Yes Vinnie you have hit the nail on the head... > I dont want A super secure program just one that the normal user wont
> accidentely dbl click the database and{*filter*}it up !!!
> You say to password protect it using access ?
> How do you then use this password protection in visual basic to allow
access
> ??
> may sound stupid to you but I am a beginner !!!
> Many thanks
> Mike
> P.S - Any chance of emailing me with any answers as I am going away for a
> couple of weeks !!
> >Hi Pete,
> >Agreed. If I were shipping an Access-based financial package for large
> >corporations and it was available for purchase by the general public, I
> >would not expect an Access password to secure it.
> >However, in several consulting projects I've worked on, the product was
> >designed not to be "secure against malicious hacking", but rather to be
> >secured so "wandering eyes" (curious employees within the company) don't
> >"mess up" any data in the database. The data was confidential, but did
not
> >contain personal information of a financial nature. Of course, all
> personal
> >information is considered confidential, but I think there are degrees.
On
> >the projects I worked on, the customers said they simply wanted to make
> sure
> >no one "accidentally" screwed up the database by messing around in
Access.
> >They didn't necessarily want the information exposed, but they also
didn't
> >see the need for an extensive encryption layer in the code to secure the
> >data against hackers.
> >Perhaps the original poster does need some type of "ultra-secure" method
of
> >protecting the database, but perhaps he only needs to keep people from
> >making "accidental changes". Or perhaps his customer is someone that
would
> >never dream of going out and spending the time searching the web for a
> >password hack just to be able to view the database. In the case of my
> >clients, they were way too busy at their jobs and didn't have time or
> desire
> >to hack into the database and locate confidential information. They
simply
> >wanted a tool to store and retrieve data with a usable interface.
> >I guess we would need more information from the original poster.
However,
> >I do think that in certain cases, a password is a quick, inexpensive
> >solution that solves the need desired by the user. It truly depends on
the
> >requirements of the individual case. But I would agree that if your
intent
> >is to secure the data from "intentional hacking", then an Access password
> >won't cut it.
> >Another interesting point this discussion raises is the ability to make
the
> >product's data open and available. Having an "open architecture"
database
> >is desirable by many product buyers because they can now write their own
> >reports and queries against the data. The desire for this type of
> read-only
> >access must be accounted for when implementing some type of encryption on
> >the database itself. If the data is encrypted inside the DB, the user
> won't
> >even be able to write reports or queries to access the data in a
read-only
> >fashion without some intermediate process to extract and decrypt it. I
> >think all these factors should come into play when the designer tries to
> >protect a database from the customer. In fact, I used to work for a
> company
> >that produced an accounting package using an Access back end. And, as a
> >matter of fact, it was more important to their client base that they have
> >unlimited access to the data through external applications (Crystal
> Reports,
> >etc) than it was to have it encrypted, and so the decided method was an
> >Access password - nothing more. The only thing that was encrypted was
user
> >ID's and passwords I guess they feel their user base simply isn't
> >interested in hacking the database, and I'd agree (knowing the
demographics
> >of their customer base).
> >--
> >Vinnie Murdico
> >Software with Brains, Inc.
> >Visual Basic Controls and Components
> >SWBTracker - Value-Priced Bug Tracking Software
> > http://www.*-*-*.com/
|
| Mon, 10 Jun 2002 03:00:00 GMT |
|
| |
|
