I'm confused about encryption

MLH

Silly me. I thought that if I clicked Tools, Security, Encrypt
database MyDB.mdb to Ncrypt.mdb I would not be able
to read the module code if opening Ncrypt.mdb inside
A97 later. I've found that was incorrect.

What's a simple approach I can use as a self demonstration
of the difference between an unencrypted mdb and an encrypted
mdb? Is it possible that I'll notice a difference if I enter the
following on the command prompt?

Type MyDB.mdb <enter> (the non-encrypted one)
Type Ncrypt.mdb <enter> (the encrypted one)

Rick Brandt

MLH wrote:

Silly me. I thought that if I clicked Tools, Security, Encrypt
database MyDB.mdb to Ncrypt.mdb I would not be able
to read the module code if opening Ncrypt.mdb inside
A97 later. I've found that was incorrect.

What's a simple approach I can use as a self demonstration
of the difference between an unencrypted mdb and an encrypted
mdb? Is it possible that I'll notice a difference if I enter the
following on the command prompt?

Type MyDB.mdb <enter> (the non-encrypted one)
Type Ncrypt.mdb <enter> (the encrypted one)

Encrypting an MDB only prevents someone from seeing its contents with a HEX
viewer or a utility like Notepad. It does nothing to prevent seeing
anything when opening the file with Access.

It has the side effect of making the file uncompressible with ZIP type
utilities.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

MLH

I don't have a HEX editor. Is there something else I have that I could
open it with to SEE for myself the difference between looking at an
encrypted mdb vs the same mdb before encryption?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

Encrypting an MDB only prevents someone from seeing its contents with a HEX
viewer or a utility like Notepad. It does nothing to prevent seeing
anything when opening the file with Access.

It has the side effect of making the file uncompressible with ZIP type
utilities.

Rick Brandt

MLH wrote:

I don't have a HEX editor. Is there something else I have that I could
open it with to SEE for myself the difference between looking at an
encrypted mdb vs the same mdb before encryption?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

Notepad

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

polite person

On Tue, 11 Oct 2005 22:44:03 GMT, "Rick Brandt" <ri*********@hotmail.com> wrote:

MLH wrote:
I don't have a HEX editor. Is there something else I have that I could
open it with to SEE for myself the difference between looking at an
encrypted mdb vs the same mdb before encryption?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

Notepad

choose a small database or be prepared to wait a long time!

MLH

Notepad! Good idea.
Well, here is my entire mdb file (trash.mdb)

Option Compare Database
Option Explicit

Sub PrintEyes()
'*************************************
' This is a comment. So is this. I have
' mostly comments in this mdb file.
'**************************************
Dim i As Integer
For i = 1 To 100
Debug.Print i
Next i

End Sub

It consists of a single module named Module1.
Opening trash.mdb with notepad, I was able to
find and read the comments. I was able to locate
the string "PrintEyes", the sub name. I was not
able to find the word "Integer" or "Debug.Print"
or even "Print' by itself (only inconjunction with
"PrintEyes"). It appears that the functional code
was well scrambled within the mdb - resembling
nothing like the text of the code we see as we
write it. I did find this little blurb...

ÿ Ä%
Access
€ ÿ
As . € ÿ
Debug =
€ ÿ
Dim U
€ ÿ
For … € ÿ
Next ´
€ ÿ
To
VBA÷â Win16Á~ Win32
Mac³²
DAOž‚ trashi
Module1b € ÿ

_EvaluateÙ
i` € ÿ

Formâ € ÿ
ÿÿ_B_var_FormNv
€ ÿ
ÿÿ_B_var_ForjL PrintEyes±w
€ ÿ
ÿÿ_B_var_Sub½’
ÿÿ

<

ÿÿ

ÿÿ

i
LVAL
u
....which seems to contain my For - Next loop. And in the
encrypted version, I couldn't find any of the comment text.
Fact is, I could find no recognizable words that I had typed
in the module.

I'm happy with the encryption. I hope its not been cracked.
If it has, then I guess doing the extra step of encryption is
not really effective. What good is a lock if a criminal has the
key to it? I do like the encryption step. Do most of you bother
to fool with it?

Brian Wilson

"MLH" <CR**@NorthState.net> wrote in message
news:av********************************@4ax.com...

Notepad! Good idea.
Well, here is my entire mdb file (trash.mdb)

Option Compare Database
Option Explicit

Sub PrintEyes()
'*************************************
' This is a comment. So is this. I have
' mostly comments in this mdb file.
'**************************************
Dim i As Integer
For i = 1 To 100
Debug.Print i
Next i

End Sub

It consists of a single module named Module1.
Opening trash.mdb with notepad, I was able to
find and read the comments. I was able to locate
the string "PrintEyes", the sub name. I was not
able to find the word "Integer" or "Debug.Print"
or even "Print' by itself (only inconjunction with
"PrintEyes"). It appears that the functional code
was well scrambled within the mdb - resembling
nothing like the text of the code we see as we
write it. I did find this little blurb...

ÿ Ä%
Access
? ÿ
As . ? ÿ
Debug =
? ÿ
Dim U
? ÿ
For . ? ÿ
Next ´
? ÿ
To
VBA÷â Win16Á~ Win32
Mac³²
DAOz, trashi
Module1b ? ÿ

_EvaluateÙ
i` ? ÿ

Formâ ? ÿ
ÿÿ_B_var_FormNv
? ÿ
ÿÿ_B_var_ForjL PrintEyes±w
? ÿ
ÿÿ_B_var_Sub½'
ÿÿ

<

ÿÿ

ÿÿ

i
LVAL
u
...which seems to contain my For - Next loop. And in the
encrypted version, I couldn't find any of the comment text.
Fact is, I could find no recognizable words that I had typed
in the module.

I'm happy with the encryption. I hope its not been cracked.
If it has, then I guess doing the extra step of encryption is
not really effective. What good is a lock if a criminal has the
key to it? I do like the encryption step. Do most of you bother
to fool with it?

The purpose of encryption is to protect the data in the tables rather than
the code in the modules. If you wanted to protect the code, you would make
an mde file.
My view on this is that since encryption comes with a performance penalty,
it is not worth bothering with. Since cracks for Access user-level security
are widely published in the public domain - the truth is you cannot protect
your data properly - so why bother with encryption?
I do use user-level security and think it does a great job at locking down
certain objects for certain groups of people. But the aim here is to keep
the application working properly and prevent people from changing things
they shouldn't - I am not trying to (nor could I) keep out a determined
hacker.
So use an mde to protect your code, but give up hope of protecting the
data - unless you use a more secure datasource for the tables (like SQL
Server or Oracle) or possibly use third party software to encrypt the
contents of the tables.

rkc

MLH wrote:

I'm happy with the encryption. I hope its not been cracked.
If it has, then I guess doing the extra step of encryption is
not really effective. What good is a lock if a criminal has the
key to it? I do like the encryption step. Do most of you bother
to fool with it?

What are you trying to protect?

MLH

Thanks, bwilson. I'm clear on purpose of encryption now. More for data
than for code. I won't bother because the data is not confidential.
The code is, so I'll rely on the mde there. Are we pretty well secured
there, with the mde I mean? I remember in Access 2.0 - wow, there
was a very large hole and it didn't even require crackers - just a
bowl of soup.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx
On Wed, 12 Oct 2005 08:41:23 +0000 (UTC), "Brian Wilson"
<bw*****@ease.co.uk> wrote:

The purpose of encryption is to protect the data in the tables rather than
the code in the modules. If you wanted to protect the code, you would make
an mde file.
My view on this is that since encryption comes with a performance penalty,
it is not worth bothering with. Since cracks for Access user-level security
are widely published in the public domain - the truth is you cannot protect
your data properly - so why bother with encryption?
I do use user-level security and think it does a great job at locking down
certain objects for certain groups of people. But the aim here is to keep
the application working properly and prevent people from changing things
they shouldn't - I am not trying to (nor could I) keep out a determined
hacker.
So use an mde to protect your code, but give up hope of protecting the
data - unless you use a more secure datasource for the tables (like SQL
Server or Oracle) or possibly use third party software to encrypt the
contents of the tables.

MLH

<snip>

What are you trying to protect?

The code & app - not the data.
Brian Wilson has pointed out that
encryption is not the tool to do it
with. I use the mde format for
distribute. Sounds like that's all
we need - or at least all we have
to work with.

David W. Fenton

MLH <CR**@NorthState.net> wrote in
news:av********************************@4ax.com:

I'm happy with the encryption. I hope its not been cracked.
If it has, then I guess doing the extra step of encryption is
not really effective. What good is a lock if a criminal has the
key to it? I do like the encryption step. Do most of you bother
to fool with it?

Using it is only relevant if you're using Jet security to lock down
your database.

And since that's been cracked (via cracking the encryption of
passwords stored in the MDW file), the encryption of the data is
really only an annoyance to slow down someone who is not smart
enough to crack Jet security.

So, no, I don't encrypt any of my databases.

Back in the days before Jet security had been cracked (or before it
was widely known that it had been cracked) I did secure one app and
encrypt the data file.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

David W. Fenton

MLH <CR**@NorthState.net> wrote in
news:48********************************@4ax.com:

I'm clear on purpose of encryption now. More for data
than for code. I won't bother because the data is not
confidential. The code is, so I'll rely on the mde there. Are we
pretty well secured there, with the mde I mean? I remember in
Access 2.0 - wow, there was a very large hole and it didn't even
require crackers - just a bowl of soup.

Yet again, someone is contemplating using an MDE without bothering
to learn what it is.

An MDE is *not* crackable, as THE CODE ISN'T THERE ANY LONGER. All
that's there is the compiled code, which is not human readable. The
only thing that's readable in p-code is the values of the constants,
which are hardwired at compile time. That won't be sufficient to
reconstruct the code.

If you had simply read the Access 97 Help topic on MDEs you wouldn't
have needed to ask the question above.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Brian Wilson

"MLH" <CR**@NorthState.net> wrote in message
news:48********************************@4ax.com...

Thanks, bwilson. I'm clear on purpose of encryption now. More for data
than for code. I won't bother because the data is not confidential.
The code is, so I'll rely on the mde there. Are we pretty well secured
there, with the mde I mean? I remember in Access 2.0 - wow, there
was a very large hole and it didn't even require crackers - just a
bowl of soup.

As David has pointed out, the mde is 'un-crackable' in the sense that the
code isn't there anymore. Now there may be some very nerdy types able to
work out what's going on by some form of nerd-wizardry, but consider this:
The best Access developers in this group could probably re-write the
application from scratch pretty quickly just by looking at it run - and
their code might well be better than the original anyway.

MLH

Damn.
I didn't know Jet security had been cracked. That includes A97?
There's no point in security measures if the passwords in the mdw
are readable. Security is fairly cumbersome to implement. If some
hacker can grab the admin superuser and owner passes, what's
the point. I would-a-thought it would have made big headlines on
this NG. I just missed it. Has it been long ago?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx

Using it is only relevant if you're using Jet security to lock down
your database.

And since that's been cracked (via cracking the encryption of
passwords stored in the MDW file), the encryption of the data is
really only an annoyance to slow down someone who is not smart
enough to crack Jet security.

So, no, I don't encrypt any of my databases.

Back in the days before Jet security had been cracked (or before it
was widely known that it had been cracked) I did secure one app and
encrypt the data file.

jimfortune

MLH wrote:

Damn.
I didn't know Jet security had been cracked. That includes A97?
There's no point in security measures if the passwords in the mdw
are readable. Security is fairly cumbersome to implement. If some
hacker can grab the admin superuser and owner passes, what's
the point. I would-a-thought it would have made big headlines on
this NG. I just missed it. Has it been long ago?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx

You missed it. Also check out:

http://www.access.vis.pl/war223.htm

Access Security is not cumbersome to implement. It's just bothersome
afterwards, yet adequate for most "inside" threats. Even MDE's are
adequate for most "inside" threats depending on how they're
implemented.

James A. Fortune

Br

MLH wrote:

Damn.
I didn't know Jet security had been cracked. That includes A97?
AFAIK every MS Office product has been cracked (documents and
installation). Many 'common use' programs have also been cracked
(potected PDFs, ZIPs, etc).

Access2 was the easiest... just use some simple code to copy all the db
objects (except the system tables) and bipass the security:)
There's no point in security measures if the passwords in the mdw
are readable. Security is fairly cumbersome to implement. If some
hacker can grab the admin superuser and owner passes, what's
the point. I would-a-thought it would have made big headlines on
this NG. I just missed it. Has it been long ago?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx

The simplest approach is to hack the database and 're-issue' the default
Admin user's rights to everything in the database. It works with all
versions of Access.

There are tools that try to crack encryption and generally they work
(but can take a long time depending on the db size).

Database passwords are also very easy to read and there are many tools
for doing that....but I think I read somewhere where that was improved
in later releases?

And there is even a tool to crack VBE project passwords.

Distributing an MDE is the easiest and most secure route (for the db
design).
--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

David W. Fenton

MLH <CR**@NorthState.net> wrote in
news:bm********************************@4ax.com:

I didn't know Jet security had been cracked. That includes A97?
There's no point in security measures if the passwords in the mdw
are readable. Security is fairly cumbersome to implement. If some
hacker can grab the admin superuser and owner passes, what's
the point. I would-a-thought it would have made big headlines on
this NG. I just missed it. Has it been long ago?

It's been discussed at length on this newsgroup over and over and
over and over again over the past few years. High-profile
participants in the discussion have included Michael Kaplan and
Peter Miller, among others. Larry Linson, I believe, has taken the
commonsensical approach that the fact that it can be easily cracked
by people in the know doesn't mean it *will* be.

Do you lock your car doors?

If so, it's about the same level of security as Jet user-level
security. Any professional thief can get into your car without
damaging it at all, but locking it keeps out most people.

Jet user-level security still has its uses at about the same level.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Trevor Best

MLH wrote:

Damn.
I didn't know Jet security had been cracked. That includes A97?
There's no point in security measures if the passwords in the mdw
are readable. Security is fairly cumbersome to implement. If some
hacker can grab the admin superuser and owner passes, what's
the point. I would-a-thought it would have made big headlines on
this NG. I just missed it. Has it been long ago?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx

Don't feel too bad, if you put a form up and ask users for their palm
print to verify or to look closely for a retina scan, over 90% will
comply without question. Access security will keep most people out.

To not implement security because it's crackable is just asking for the
casual user to crack it.

MLH

Holy Shit! I'm just behind the times. I was using
Access 2.0 just because I knew it well. I knew
it had no security. I didn't care - it wasn't an issue.
The code I was writing certainly wasn't rocket
science. I don't even lock my door when I leave
the house to go to the movies - call me foolish,
but if someone wants what you've got bad
enough - they will find a way to get it. Sadam's
oil, for example.

I moved to Access 97 AFTER all this shit had
hit the fan already. I wasn't keeping up with
any of the gossip. Well, I'm not surprised.

MLH

Well, that's a bummer. I don't even know what a database password is.
Of course, I know about user passwords. I would assume the database
password is the userID and password pair belonging to the superuser
(or owner) of all the objects in the database. Is there some other
password that I'm missing here???

Database passwords are also very easy to read and there are many tools
for doing that....but I think I read somewhere where that was improved
in later releases?

MLH

You and David are right. To me, there's probably no consequence
in anyone having access to every object I've ever pasted together.
Nothing I write is rocket science. That much is for sure. I just liked
the idea of thinking that nobody but I could get to the intimate
details of my stuff. I've counted on the presumption that if I wrote
it and wrapped it up tight, I would be the only source for subsequent
callback for further development. That's about it - my only concern.
Now that I know that's not the case, it changes nothing but my
presumption. I'll continue to implement and roll-out security and
mde's and all that. Any customer having an employee who knows
how to type http://www.access.vis.pl/war223.htm and click Go
can wash me out of future considerations literally with no more than
an afternoon's effort. Just remove my app's security, email it to his
buddy and say "Hey, can you improve on this for us?"

No biggie, I'll just get my money up front - enough to justify time
spent and count any future revenues as a windfall. What else can
you do?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx

Don't feel too bad, if you put a form up and ask users for their palm
print to verify or to look closely for a retina scan, over 90% will
comply without question. Access security will keep most people out.

To not implement security because it's crackable is just asking for the
casual user to crack it.

Rick Brandt

MLH wrote:

Well, that's a bummer. I don't even know what a database password is.
Of course, I know about user passwords. I would assume the database
password is the userID and password pair belonging to the superuser
(or owner) of all the objects in the database. Is there some other
password that I'm missing here???

No, there is a separate database password you can apply ( no user name) that
is completely separate from User Level Security and even easier to crack.
It is similar to putting a password on a Word Doc or Excel file.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

David W. Fenton

MLH <CR**@NorthState.net> wrote in
news:gl********************************@4ax.com:

Any customer having an employee who knows
how to type http://www.access.vis.pl/war223.htm and click Go
can wash me out of future considerations literally with no more
than an afternoon's effort. Just remove my app's security, email
it to his buddy and say "Hey, can you improve on this for us?"

Would you want to do business with a client who would do that to
you?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

David W. Fenton

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:ZF****************@newssvr11.news.prodigy.com :

MLH wrote:
Well, that's a bummer. I don't even know what a database password
is. Of course, I know about user passwords. I would assume the
database password is the userID and password pair belonging to
the superuser (or owner) of all the objects in the database. Is
there some other password that I'm missing here???

No, there is a separate database password you can apply ( no user
name) that is completely separate from User Level Security and
even easier to crack. It is similar to putting a password on a
Word Doc or Excel file.

And it was always worthless and caused all sorts of problems (e.g.,
in replicated databases).

I see it as yet another example of the managers of the Office
product family having zero understanding of what Access is, and
trying to make it consistent with Word and Excel, which both offer
document passwords. The problem is that a database is not a
document, but the people pushing this decision were too stupid to
know that.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Trevor Best

David W. Fenton wrote:

MLH <CR**@NorthState.net> wrote in
news:gl********************************@4ax.com:

Any customer having an employee who knows
how to type http://www.access.vis.pl/war223.htm and click Go
can wash me out of future considerations literally with no more
than an afternoon's effort. Just remove my app's security, email
it to his buddy and say "Hey, can you improve on this for us?"

Would you want to do business with a client who would do that to
you?

Aside from that, the terms "Copyright" and "IPR" spring to mind.

Unless of course you do something for the MOD and miss their clause that
gives them the rights to do anything they want with your code despite
the fact that you retain the IPR.

MLH

Most definitely.

On Wed, 12 Oct 2005 21:19:59 +0000 (UTC), "Brian Wilson"
<bw*****@ease.co.uk> wrote:

The best Access developers in this group could probably re-write the
application from scratch pretty quickly just by looking at it run - and
their code might well be better than the original anyway.

MLH

I'm guilty. Well there you have it, then. The MDE, as it turns out,
suits all my needs. It would seem that encryption is a step I can
do without when distributing MDE's.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Yet again, someone is contemplating using an MDE without bothering
to learn what it is.

An MDE is *not* crackable, as THE CODE ISN'T THERE ANY LONGER. All
that's there is the compiled code, which is not human readable. The
only thing that's readable in p-code is the values of the constants,
which are hardwired at compile time. That won't be sufficient to
reconstruct the code.

If you had simply read the Access 97 Help topic on MDEs you wouldn't
have needed to ask the question above.

MLH

Depends on how much I get up front, I guess.
Based on my historic earnings, I would say NOT.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Thu, 13 Oct 2005 17:35:11 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Would you want to do business with a client who would do that to
you?

I'm confused about encryption

This discussion thread is closed

Similar topics