<fishqqq (AT) hotmail (DOT) com> wrote

Ok, a quick google for encrypting access tables gives me this;

http://www.access-programmers.co.uk/...ad.php?t=50060

Create textbox Text1 on form bounded to your table field which contains some
data.

Private Function Encrypt(sData As String) As String
Dim sTemp, sTemp1, tt As String
Dim ii As Integer
For ii = 1 To Len(sData)
sTemp = Mid(sData, ii, 1)
tt = Asc(sTemp) * 2
sTemp1 = sTemp1 & Chr(tt)
Next ii
Encrypt = sTemp1
End Function
-----------------------------------------
Example to call this function:
Text1=Encrypt(Text1)


The above function takes a string, messes with it and returns a string that
should be unreadable. So I suppose (and I can feel myself getting out my
depth) "encrypt" your key tables in this way before shipping, then you'll
need a Decrypt function when the form loads up with the bound controls -
presumably in the on Current event.

I don't see the Decrypt function but presumably hacking the above function
to get it working in reverse is possible.

fishqqq (AT) hotmail (DOT) com wrote:
It limits what menus and such the user can get to when they open the
file, but all of those (as well as your hide the tables idea) are only
effective against users that have no familiarity with Access. Anyone
that has spent enough time in Access to search forums and newsnet for
answers will easily know how to get around all of that.

"Access Developer" <accdevel (AT) gmail (DOT) com> wrote in
news:919ejfF18aU1 (AT) mid (DOT) individual.net:

But that's no longer true from A2007 on. The encryption is quite
strong now. This is MS's answer to the removal of ULS from the ACCDB
format, weak as it is. It's not the encryption that's weak, but the
implementation (you can't really get around the fact that you either
have to provide users with the password or you have to hardcode it
in your front end).

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"fishqqq (AT) hotmail (DOT) com" <fishqqq (AT) hotmail (DOT) com> wrote in
news:e549d43e-59a0-46f3-8906-2a3669dca5ff (AT) q12g2000prb (DOT) googlegroups.co
m:

You have two choices:

1. since you're using MDB/MDE format, you can use Jet user-level
security. While that's crackable, it's not going to be something
your garden-variety user is going to be able to work around.

2. use a different back end, a server database like SQL Server
Express, that has its own independent data security.

Your comments about MDEs are incoherent, actually. You can
distribute an MDB with the runtime, and the MDE vs. MDB format has
nothing to do with security of the data tables -- it only applies to
your code-bearing objects.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"David-W-Fenton" <NoEmail (AT) SeeSignature (DOT) invalid> wrote

I'm neither a security-breaking-hacker nor a security expert, but from what
I hear and read, the overall database password, however strong its
encryption scheme may be, is still "not very" secure. My suggestion
remains: secure your data by putting it in a server database with good
security, and take a tranquilizer to stop worrying so much about someone
stealing the clever inventions in your application.

Larry Linson
Microsoft Office Access MVP

David-W-Fenton wrote:

pw of "secback". Created a frontend, linked to table on backend by
entering the pw. Then encrypted frontend with pw "secfront".

When I enter the frontend I am prompted for pw, enter the frontend pw,
and I have access to backend linked table.

The major problem I see is that one can simply get the connectstring to
get the pw to the backend.

Then one could swipe the backend mdb onto a cd or whatever and open it
up with its pw later on.

Since there are ways of decompiling an MDE (I assume accde as well) I
would think an Access app could never be secure.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:gN2dnc62pZhfdCjQnZ2dnUVZ_gudnZ2d (AT) earthlink (DOT) com:

There is nothing at all new about this. If you stored passwords to
ODBC server databases in your linked tables, you had the same
problem. If you hardcoded them in your VBA (and created your linked
tables on the fly), you had the same problem. The key then to
avoiding the problem was the combination of Jet user-level security
and encryption, the former to keep people out of the design of
objects, and the latter to hide the password in the code.

All of the flaws you adduce have always been present before the
current regime, it's just that there are now fewer tools to create
roadblocks to make it more difficult to break.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Ron Weiner <NoOne (AT) NoWare (DOT) NutThing> wrote in
news:ip5924$g2f$1 (AT) dont-email (DOT) me:

But isn't the seed value embedded in your executable somewhere?

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

on 4/27/2011, David-W-Fenton supposed :
Yup sure is, but is spread across several modules/forms. Those pieces
are also encrypted using what might be described as a non obvious
decryption algorithm. I.E. the key dosent look like a key should one
peruse the exe using a hex editor.

Could it be cracked? Yea you betcha', but the effort required would
eliminate all but the most determined and knowledgeable persons. Again
we are willing to live with that level of risk.


Rdub

Encrypting data is one way to do it. It can (and has) been done in
Access to standards that follow FIPS, and it can be made robust and
reliable. What cant be done in following this approach is to put the
experience and skills of a suitable crypto capable programmer who
truly understands risk into the head of a non experienced person.
Implementing crypto is not a trivial task if it is to be properly
secure.

It is possible to keep the 'master' key to a table completely
encrypted and still have a fully functional application. You have to
have a user login system that verifies that a user has access to the
DB, and using their password decrypt a copy of the master key that has
been encrypted specifically to the users details. Doing this type of
permission system in Access is a lot of work. Your tables contents are
encrypted with the master key, and the master key is in turn encrypted
individually for each user login. The effect of this on performance is
quite heavy both in terms of processing and doing even simple SQL, as
everything needs to be decrypted before it can be used. You end up
writing a lot of 'handler' functions, and you lose the benefit of
indexing if you implement crypto properly (using salts so that the
same text does not encrypt to the same ciphertext each time it is
encrypted).

The easier way to achieve what you want, but at the cost of
portability, is to use a database server that utilises a suitable
permissions scheme. SQL Express is one (albeit small scale IMO), full
SQL Server, and for some free ones MySQL (my favourite for working
with Access), and Postgres (really really really capable but probably
not for a novice). If you are really paranoid you can place stored
procedures in the server(s) to do the data handling for your app,
though I have only ever found the need to do this on a very limited
basis - it is much easier to keep your applications code in a single
place and linked tables in Access combined with passthrough queries
are extremely fast and effective.

Implementing a BackEnd (BE) server with something like SQL Express or
MySQL is a relatively cheap and easy thing to do. BE servers can give
you lots of other wonderful goodies like scheduled backups,
replication, and so on too. Pick the right tool for the job.

Would you protect a customers data from themselves? Probably not.
Protect company data from being 'ripped' by an employee - every time a
resounding YES. I am currently working on an app for this exact reason
that is using Oracle as the BE.

My advice to you: Talk to your IT dept, find a database admin and
discuss how you can migrate your app from an Access BE to a server
based BE with permissions etc... to suit your risk model.

Cheers

The Frog