473,320 Members | 1,846 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Security - more complex than I thought

S**t for brains strikes again!

Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could
read the data and some who couldn't but that it wasn't important right now.
And I said, 'sure, we can do that later'.

So now I've developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!

I've experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually
want (basically) 2 NT groups, readonly and readwrite, I find now that there
are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that'll
have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank
(because the user hasn't got permission to append?) so hiding any of my
navigation buttons. etc. etc.

As a quick and dirty approach...

I though I'd set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is
a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to
using all the user/group permissions.

What approaches does anybody else use?

Apart from planning security from the beginning, properly, of course.

TIA, Mike MacSween (feeling like a chump)
Nov 12 '05
116 7375
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:gn********************************@4ax.com...
On Fri, 14 Nov 2003 12:32:20 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net. ..
If they have permission to use the database, I don't know how you can
prevent this scenario. They must have full permissions on the folders to be able to _use_ it,


I don't think so. They have to have _some_ permissions on the folder. That isdifferent to the permissions they need to have to the back end data file (ifthat is the way it's implemented).


You are correct, in a limited way, Mike.
And I specifically deny them List Folder/Read Data.

On the BE file contained in that folder give them read and write if you
want.

I logged on as one of those users. I couldn't get to the back end data filedoing an ordinary windows explorer browse.


Right, and then you tried going after the file directly (by specifying
its full path and name instead of simply browsing the parent folder),
and what did you find? I thought so.


Well, I just tried that. Maybe I'm missing something. But no, I couldn't get
at it. I typed the full UNC path into the address bar -
\\server\sharename\filename and got a 'couldn't find file' message. I then
changed the permissions on the back end file and did exactly the same thing
and found I could get to the file, so it's not that I'm typing the address
in incorrectly. F3 didn't get to it either. Is this what you meant? What
results did you get when you tried it the way I have? How did you get to the
back end data file that's in a folder set up the way I've described. I'm not
saying you're arrogant or anything, but it might be an idea to actually try
what I've described. It's a 5 minute job for anybody with a Win2K network.
Or maybe you don't want to waste 5 minutes proving me wrong. I'm sure I've
just missed the point of what you were saying, but I don't know how.

Mike MacSween
Nov 12 '05 #51
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

Right, like that. Thanks very much. That to me is relatively sopisticated.
It requires knowledge of file names and computer use beyond the normal
browse, point, click approach that most users are used to. They actually
need to type. And to know where and what to type. And still only gives the
user the permissions granted by NT, I think. But I'll investigate some more.

Still, took me a fair time to get there didn't it?

OK. This thread has actually got the point where there is an outside chance
that the weak security that can be applied to security is actually being
made weaker for me, in this instance. By which I mean that one of my users
who is web savvy enough might actually do a search for 'access, password,
security, Mike MacSween'. So the way in that you just guided me towards I
don't want to reveal. That may seem like massive paranoia. But right now I
can't remember who I've told - 'there's some really useful info on the
web/in newsgroups, I often post there'.

Yours, Mike MacSween
Nov 12 '05 #52
On Sat, 15 Nov 2003 06:00:05 -0000, "Mike MacSween" <mi******************@btinternet.com> wrote:
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
Obscurity is not security, and it is irresponsible and unrealistic toassume
this is good enough, for anyone.

<snip>

In this particular case:

1. Only those people who know about the database even know it exists. They
may or may not tell their friends/relatives and so on.

2. At the moment the people who know about the database already have some
access to it.

3. They would need a desire to change the data without authority.

4. Theft of the data would not bring down the organisation. It may
constitute a breach of the data protection act, especially if it were widely
published.

5. Unauthorised alteration of the existing data is more of a concern. It's a
database for recording student marks. Students are the ones who might want
to alter marks. They have to get past NT security first. It's on a domain
they don't have access to, in the ordinary course of events. Of course,
people leave machines on etc. etc. We know that NT security can be
circumvented in various ways, often 'socially'. That is beyond my control.
And of course the same caveat applies to all the college's data.

6. The academic process involves the discussion of each student's overall
year mark, then degree award, at a board of examiners. Usually 10-20 members
of the academic staff, most of whom will know the students' work fairly
well. Borderline students are always discussed. A student who had
significantly higher grades than was expected would be noticed, I think. The
parts of the course which contribute to the class of degree contain only 7
modules. Some of those modules might only contain 1 or 2 assignments. There
is a high probability that the member of staff who marked those assignments
will be present and would remember that actually Jo Soap didn't get 80 for
that piece of work, but 55. And the marks are always recorded in paper form
first, and that list of marks is present at exam board. That brief outline
of how the system is used is why I don't think that you have enough
information to comment on whether Access security (and anything else I might
use) is 'good enough' for me. You don't know the context in which the
application is used. I do. No doubt there are plenty of 'ah, but what ifs'
you have ready for me. I'd be interested to hear them.

7. I will present a precis of this thread to the management of the college,
incorporating a summation of your, Peter's and others' comments. At that
point my professional duty is done. The college management can then make the
decision whether to abandon computerise record keeping, move to a database
server system, or continue with what I'm developing for them.

Yours, Mike MacSween


So we all agree that Access security is severly flawed.
You have mentioned several methods you can employ to make manipulation of the data file more difficult for many users. In the scenario you have
outlined above I would be inclined to build an interface which would make the data meaningless without the front end, and tightly control how the
scores are entered in the front end. This would, to a large extent make the Access security flaws irrelevent.

In your scenario it would appear that in reality the score is the critical data piece that must be protected. Therefore I would design an interface
specifically designed to protect the integrity of the score.

I would create a set of custom encryption / decryption functions eg -
'================================================= =
Function fEncryptScore(curScore As Currency, intRevNo As Integer) As String
fEncryptScore = (((curScore * 10000) / 123) + 456)
fEncryptScore = fEncryptScore & intRevNo
End Function
'================================================= =
Function fUnencryptScore(strEncryptedScore As String) As Currency
Dim strCheckScore As String
strCheckScore = Left(strEncryptedScore, Len(strEncryptedScore) - 1)
fUnencryptScore = ((strCheckScore - 456) * 123) / 10000
End Function
'================================================= =
Use whatever calculation you like as long as it is reversable.

?fEncryptScore(75,1)
6553.560975609761

?fUnencryptScore(6553.560975609761)
75

Make sure the FE is an mde so the functions are not {easily} readable.

The score would be entered via an unbound textbox in a form and encrypted by your function and stored in it's encrypted form.
Me.ScoreField = fEncryptScore(Me.ScoreEntry, Me.RevNo)

Once the score has been entered I would never allow the record to be edited. If the score needs to be changed I would add a new record and leave the
existing record intact. I would include a Revision No, EnteredBy (CurrentUser()), and TimeStamp (Now()) fields in the table containing the score. Up
the RevNo by 1 each time a new record is added for the student.

The score would only be displayed in the form in a disabled textbox using the function -
=fUnencryptScore(Me.ScoreField)

If the datafile is opened directly the score will display a meaningless number.
Without the encryption key, editing this number is a hit and miss affair.

If the record is edited using the frontend you will have a 2nd record added for the student. If you have suspisions about the score you could verify
with the CurrentUser entered in that record whether they did in fact change the score.

If they get real smart and change the score in the frontend and then open the table and copy the new score to original record and then delete the 2nd
record, the last digit of the encrypted score (RevNo) will not match the rev no of the original record.

You could then write a loop to search for *suspicious* records (more than 1 record for student / RevNo does not match encrypted value)

Obviously this is a simplified example and your actual requirements will be far more complex than you have outlined, but my point is that the problem
can be tackled from more than one direction.

I do NOT claim that any of the above provides 100% security or is better or worse than any other method, it is merely another layer of defence that
can be employed which has no dependancy on Access Security (apart from getting the CurrentUser).
I certainly would NOT recommend this method (or similar) for cc or other highly sensitive data and in your case, as Peter and David have stated
previously you MUST fully discuss whatever method(s) you choose with the people responsible for the database and allow them the final decision.

Personally I wouldn't use Access for any secure purpose unless (ImportanceOfData <= (EffortToCrack /2))
But there are many, many purposes that meet this criteria.
Wayne Gillespie
Gosford NSW Australia
Nov 12 '05 #53
Mike,

My only issue with this whole thread is that you truly ARE underestimating
the abilities of users to either circumvent you methods or find someone else
who can. Anyone who thinks you have to be a Peter Miller to get in to a
database is actively deluding themselves.

The problem with this thread is that it tends to cause people to
overestimate the capabilities of security in Access/Jet, as it leads to that
"its good enough" kind of feeling, when it truly isn't.

Thankfully, I have no account at Chase (and have actively worked with other
banks to get them to enforce a "no Jet for data" policy), I hate ebay, and I
will downgrade my use of Amazon from seldom to never (not a big loss for me,
really).

Philosophically, we live in a time where there are hackers and crackers, and
any product that does not actively work to cover known security holes is (to
me) not a product that should be used if security is an important criterium.
I use Access 2002 to handle a lot of the (Unicode) source data used for
collation -- several gigs of it. And the queries/code I use on these
databases are quite sophisticated. But no security needed, so no worries for
me.

But truth be told, I would rather drop the whole thread. You are not going
to be believe me unless I were to actively worked to hack your developed
apps, and I am not the type of person who does such things.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

Nov 12 '05 #54

Wayne,

On Sat, 15 Nov 2003 11:31:46 GMT, Wayne Gillespie
<be*****@NObestfitsoftwareSPAM.com.au> wrote in
comp.databases.ms-access:
I do NOT claim that any of the above provides 100% security or is better or worse than any other method, it is merely another layer of defence


One that is completely bypassed by the student opening the backend and
copying the encrypted score from Tommy Braniac's student record to his
own, without ever worrying about the encryption.

Yes, yes, you can compensate for that too, but the point is that
adding more and more simple obfuscation layers doesn't really do all
that much to improve security - all it really does is comfort the
owner of the data that they are protected. That is why security by
obscurity is always considered completely wrong-headed by the crypto
community.
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #55

Mike,

On Sat, 15 Nov 2003 07:23:00 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
Still, took me a fair time to get there didn't it?


I don't think you really want to push that line of argument too
strongly...

Look, here's the deal. You're talking as if all this stuff is rocket
science. You probably think that the openness you just discovered is
obscure and not at all obvious to a clueless user, but I disagree.

Here's why.

The way to beat most security systems is not to read up on the
manuals, study code samples, push new boundaries, expend great brain
power, blah, blah, blah. Instead, a common and quick route to success
is simply to think about what the system must be doing/allowing in
order for an authorized system to work (any Access application has to
be able to at least read data to display it) and then knowing that, do
likewise outside of the system. Point being that I never tried the
method I proposed, nor did I sweat it when you said it didn't work,
because I knew it *would* work because I knew that you had not,
through the o/s, prevented the file from being read, because I knew
you could not do that without Access failing to draw back the data to
display it. It was trivial. You pointed out permissions that you had
pulled from the file hierarchy, but I knew there was one permission
that you had not and could not pull or your app wouldn't work. I
won't get more specific so you don't fret about your student's google
searches - BUT AT LEAST YOU ARE NOW CONSIDERING IT POSSIBLE THAT
POTENTIAL MALEVOLENT USERS OF YOUR SYSTEM WILL KNOW HOW TO SEARCH THE
NEWSGROUPS/INTERNET - something Michka and I told you a lot earlier
was something that you had to take into consideration even for your
most clueless users (hey, will that be a problem too - the way you've
referred to the users of the system in past posts? <just kidding>).

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #56
"Peter Miller" <pm*****@pksolutions.com> wrote...
That is why security by obscurity is always considered completely
wrong-headed by the crypto community.


Ah, but it is alive and well in comp.databases.ms-access! :-)
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

Nov 12 '05 #57
pm*****@pksolutions.com (Peter Miller) wrote in
<f1********************************@4ax.com>:
Now in the case of Access, I'm not at all suggesting it should not
be used at all. Its a fine rad tool. But I am suggesting that
anyone who thinks that Access security provides them with any
meaningful level of security is terribly mistaken.


I disagree, because you are no defining "meaningful level of
security" in terms of the requirements of the application.

The level of security provided by Access may very well be
sufficient (i.e., "meaningful") for a particular application.

The problem comes in when people overestimate or oversell the level
of protection afforded by Access. On that, we agree.

But I don't see that in the present instance, Mike MacSween is
making any claims to his client that are unsupportable or
exaggerated. If the client finds that level of protection
sufficient, in terms of the budget, expected operating environment
and their estimation of the risk of someone malicious gaining
access to the application, then I see nothing wrong with using it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #58
pm*****@pksolutions.com (Peter Miller) wrote in
<91********************************@4ax.com>:

David,

On Fri, 14 Nov 2003 20:55:39 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
But Mike is specifically talking about things that you can do
that erect barriers to prevent mis-use of the application and its
data by the regular users doing their usual tasks.

I think it's reasonable to do most of the things Mike has talked
about, as long as you understand that you're still exposed to the
risk from those who are not your regular users and how have
sufficient knowledge to circumvent the things you've put in
place.

Bus shelters are pretty useless from protecting you from
absolutely all wind, rain and snow, but I'm certainly glad they
are there when I have to stand on the corner waiting for the bus,
because they at least allow you to be sheltered from some of the
wind, rain and snow. That is better than no shelter at all.


But of course. I agree 100%.

But what if you suggest that by putting a letter-box outside the
bus shelter, and a bathroom, and make the seats kind of plush and
couch-like, that your bus shelter is starting to look awfully
comfy and somewhat house-like. Do I have a problem with any of
these modifications? Of course not (similarly, Mike should make
all the enhancements to Access security he likes). But if you
actually try and pass off the bus shelter as a house, you're being
less than forthright. Likewise, if Mike tells his clients that
his super-enhanced security model is anything other than a simple
deterrent to unintentional misuse, he is, in my view, being
misleading.


I don't see from anything that Mike has written that he is doing
anything of the sort. Seems to me he's suggesting putting up a bus
shelter to keep out some of the wind, and nothing more.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #59
pm*****@pksolutions.com (Peter Miller) wrote in
<t0********************************@4ax.com>:
I honestly and sincerely
believe that telling clients that Access security (and that which
you can build on your own on top of it) is anything other than
terribly weak and flawed is doing them a disservice.


But with Access alone and no outside expertise, you can't break the
security.

For someone to do so, they'd need to know a number of things:

1. that the application is secured in any way at all (most end
users never need to know anything of the sort).

2. that there exists something called "Access security".

3. that this security is crackable.

4. that the cracks for this security are readily available.

Then they'd need the expertise to use those cracks.

I've never looked at these solutions (I have no interest or need),
so I don't know if they are standalone executables or simple VBA
code, or if they utilize any kind of encryption cracking libraries
or what. Nor do I know what you get from these, a fully unsecured
file or the information necessary to unsecure it.

But they'd need certain skills to use such a utility unless it's a
"run an executable, point it at the file you want unsecured and
supply the filename for the unsecured version." If that's the case,
then, yes, it could be done by someone who knows the four pieces of
information above.

Most end users don't know those things.

Most people of good will don't know those things.

Most people of good will would never act on them if they don't.

So, you're only worrying about the people of ill will who have a
little bit of knowledge.

With Mike's additional techniques, this person would also need to
know:

1. that the data files are not stored in the front end.

2. how to locate the back end data file in a secured front end

3. how to navigate to the back end.

Those are trivialities to us, but basic conceptual difficulties
that could stop certain kinds of people in their tracks.

I see these steps as ways of preventing "knows enough to be
dangerous" types from mucking around with things. Clearly it won't
protect your data from someone with the knowledge I've outlined as
necessary.

But I still think that protecting you from all the rest of them is,
in fact, worth doing.

You seem to think that it is not.

And that's why I have a problem with these blanket condemnations of
the kinds of things Mike is doing. Your position basically boils
down to the idea that the erection this level of barries is
worthless in all cases, and not worth the time or effort.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #60
pm*****@pksolutions.com (Peter Miller) wrote in
<4a********************************@4ax.com>:
On Fri, 14 Nov 2003 20:57:28 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
Seems to me Mike is telling his clients not "pretty good" but
"good enough for the circumstances we've foreseen and within the
budget we've got and within the estimation of potential risk that
we foresee at the present time."


Really? You really think that the clients will take "good
enough for the circumstances we've foreseen and within the budget
we've got and within the estimation of potential risk that we
foresee at the present time." as being anything less than an
endorsement of the security capabilities of their application?
I'd say that such a statement would very much be taken by the
client as 'don't worry about security in this app - it's up to the
task'.


If the statement is true, then it *is* up to the task, as the task
is defined.

You're defining the task itself differently than Mike is, and that
was the point of my long definition, to define the task in terms of
the client's specific situation.

There is no circumstance in which security can be considered that
does not need to be defined as "sufficient for the circumstances
we've foreseen and within the budget we've got and within the
estimation of potential risk that we foresee at the present time."
That is the definition that applies to security considerations of
any organization, any application, any database.

You seem to be arguing that the only worthwhile protection is "more
than sufficient for the circumstances we've foreseen, etc."

At least, that's the only way I can see it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #61
mi*****@online.microsoft.com (Michael (michka) Kaplan [MS]) wrote
in <3f********@news.microsoft.com>:
Obscurity is not security, and it is irresponsible and unrealistic
to assume this is good enough, for anyone.
I, for one, have said exactly that.

What Mike is looking for is *not* security. He's simply looking to
make it harder for the casual user to much around with things that
aren't their business.
Please let me know what companies you do this for who find it an
acceptable practice, so I can be sure to never trust them with any
credit card information?


None of them do business with credit card numbers.

If they did, I wouldn't be implementing the kind of protection I'm
talking about.

Why do you assume that Mike and I are not smart enough to make that
kind of judgment?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #62
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:
Like David and the 1000s of other developers who apply the
built-in security, and NT permissions, and maybe a few ideas of
their own.


For what it's worth, I have only ever built one fully secured
Access application, ever, and applied security to one application
built by someone else.

I mostly use Jet user-level security only for user identification,
and in turn for enabling/disabling certain features in an
application.

Why?

Because I long ago concluded that the main issues with security are
making sure your network cannot be attacked and then trusting your
employees. Neither of those issues have anything to do with Access.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #63
pm*****@pksolutions.com (Peter Miller) wrote in
<su********************************@4ax.com>:
Wayne,

On Sat, 15 Nov 2003 11:31:46 GMT, Wayne Gillespie
<be*****@NObestfitsoftwareSPAM.com.au> wrote in
comp.databases.ms-access:
I do NOT claim that any of the above provides 100% security or is
better or worse than any other method, it is merely another layer
of defence
One that is completely bypassed by the student opening the backend
and copying the encrypted score from Tommy Braniac's student
record to his own, without ever worrying about the encryption.


How, exactly, does the student know that he's getting a good score?
And how long does it take him to identify a good student?

You're assuming a linear encryption.

You're also assuming the encrypted data can be understood
sufficiently to be interepreted by a human being well enough to
allow them to copy data.

Say, for instance that a grade was recorded in *two* tables, one
with the encrypted grade and another table (not enforced via
referential integrity) that was either some kind of log or some
kind of related record necessary for interpreting the other record.
If the student munging the database didn't know to copy both
records, then the data would be invalid, and the munging
detectable.

It's possible to make a system complex enough that it's not really
reasonably possible for a human being to be able to figure it out
just by looking at the raw data.
Yes, yes, you can compensate for that too, but the point is that
adding more and more simple obfuscation layers doesn't really do
all that much to improve security - all it really does is comfort
the owner of the data that they are protected. That is why
security by obscurity is always considered completely wrong-headed
by the crypto community.


Any form of encryption is really just a sophisticated form of
security by obscurity, since if you have sufficient information
(the relevant decryption key(s)), you can retrieve the original
information. What Wayne has described is simply the basic idea of
using a complex structure to store the information, a structure
that is not sufficient by itself to be interpretable, i.e., you
have to have the key to convert it to something
human-comprehensible.

To me, the real way to protect this data is to have strong account
policies for the users who have permission to edit the data, such
as locking the workstation after a small inactivity period, and
requiring strong passwords for those users, and also giving only
extremely limited access to the server on which the data is stored
(including limiting that access to only a small number of
workstations, for instance), and, of course, limiting access to the
share where the data MDB is located only to those users who should
be editing it.

Personally, I think all of that is much more important than mucking
around with Access to try to make it harder to understand the raw
data. If they can't get to that data in the first place, then
there's no risk from the students.

Spending lots of time making the data storage structure
non-transparent is only worth it if you consider the risk to be
reasonably high that someone will be able to break through all the
network layers to get access to the raw data file.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #64
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
It's perfectly reasonable to depend on Jet user-level security
and NT permissions and logging for a certain level of protection
against user exploits, given a certain determination by the
organization that the cost/benefit ration is appropriate for the
level of risk they are willing to be exposed to.


Thank you David. A simple enough point. And just the one I'm
trying to make.


But it's one that Michael and Peter will never acknowledge in
public in this newsgroup.

We all understand that Jet user-level security can be cracked and
fairly easily and completely by a person with motivation to do so.

You used the analogy of your locked door early on in this thread,
and I've often used the one of automobiles -- you lock your car
doors even though you know that anyone with a simple, inexpensive
tool can open that door in seconds.

I see using the techniques outlined above as nothing more than
locking the car door. It's prudent to do so because it keeps out
some people.

And that's worth something.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #65
pm*****@pksolutions.com (Peter Miller) wrote in
<4c********************************@4ax.com>:
The way to beat most security systems is not to read up on the
manuals, study code samples, push new boundaries, expend great
brain power, blah, blah, blah. Instead, a common and quick route
to success is simply to think about what the system must be
doing/allowing in order for an authorized system to work (any
Access application has to be able to at least read data to display
it) and then knowing that, do likewise outside of the system.


Even a lot of developers who use Access/Jet all the time do not
understand how Jet works. How often have we seen people post saying
that putting an MDB on a server makes your application
client/server? Indeed, we had someone a while back who continued to
insist on just that, even after it was explained in detail that
this was not the case.

I, too, was skeptical of Mike's comments about preventing access
with NT security, for the very reasons you cite. But I still think
what he proposed was worth something.

But, again, it's only going to help someone who's already logged in
as a user who is given the level of access to the MDB necessary to
edit its data. And I think your first line of protection is in
making sure that the circumstances in which someone can do that are
as narrow and restricted as possible. And much of that involves
network architecture, not NT or Access security (i.e., restricting
logon to certain IP addresses, maybe even restricting it to certain
MAC addresses).

Even doing all of that, someone in the office of an authorized user
who left their PC logged on could then get into the data and muck
around with it. But that's a vulnerability of *any* database
application, so I don't think it's really valid to put the burden
there on Access alone.

Now, the vulnerability is not exactly the same.

With an Access back end, you don't need the application or an
authorized login to manipulate the data, as you would with, say, a
SQL Server back end.

But to steal or alter the MDB file if the network and NT security
infrastructure was properly restricted, these things would have to
happen:

1. an authorized user has to leave her machine logged on and
unattended.

2a. the network policy must have no timeouts that will log off or
lock the workstation after a short period of inactivity, OR

2b. the hacker must get access to the unattended logged-on machine
before the timeout expires.

3. the hacker must know what application is used for storing the
information he wants to hack.

4. the hacker must know how to look at that application and figure
out it's stored in an Access MDB.

5. the hacker must know how to figure out how to located that MDB
file from the information available in the front end MDB.

6. the hacker must know how to bypass any restrictions on the front
end MDB that protect the information about the location of the back
end data file.

7. having located the back end, the hacker must know how to gain
access to the Jet-secured back end.

8. having gained access, the hacker will need to examine the data
structure and figure out how to change the data without being
detected.

9. the hacker must do all of this without being discovered working
at the PC of the absent office worker.

How likely are all of these things?

Possible?

Absolutely.

But if the machines that are authorized are not in locations that
students have access to and have appropriate policies applied, then
the window is very narrow.

Now, it's possible that a hacker could just ship a copy of the file
of to a different location, then at her leisure, hack the data
structure and figure out how to undetectably alter the back end,
then they'd have to have a moment of opportunity to be back at an
unattended, logged-on workstation to munge the data.

There are a whole lot of ifs here, a whole lot of knowledge
necessary, and a whole lot of opportunities needed.

Yes, it could all come together, but it is not something that could
happen, I believe, without planning and luck *if* the working
environment is appropriately limited, i.e., if the locations from
which the data can be accessed are severely limited and controlled.

What you do in Access to make things less obvious only add to the
amount of time it takes to munge the data once the opportunity to
work at the unattended workstation has presented itself. So, to me,
the first line of defense is actually making sure that unattended
logged-on workstations are the exception, and that the likely
hackers are not given access to those machines, unattended or not.
And password policies have to be very strong and the network
infrastructure designed to be as narrowly available as possible.

But I still think the things you *can* do with Access itself are
worth doing, as people do leave their workstations unattended, and
unauthorized people can sit down at those unattended workstations.
Putting up a few more barriers in Access simply increases the
amount of time needed to break the system, and I think that's worth
it, if one assumes that someone gets through all the policies and
procedures and mechanisms put in place to reduce that chance that
someone gets that far in the first place.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #66
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:4c********************************@4ax.com...

Mike,

On Sat, 15 Nov 2003 07:23:00 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
Still, took me a fair time to get there didn't it?
I don't think you really want to push that line of argument too
strongly...

Look, here's the deal. You're talking as if all this stuff is rocket
science. You probably think that the openness you just discovered is
obscure and not at all obvious to a clueless user, but I disagree.

Here's why.

The way to beat most security systems is not to read up on the
manuals, study code samples, push new boundaries, expend great brain
power, blah, blah, blah. Instead, a common and quick route to success
is simply to think about what the system must be doing/allowing in
order for an authorized system to work (any Access application has to
be able to at least read data to display it) and then knowing that, do
likewise outside of the system. Point being that I never tried the
method I proposed, nor did I sweat it when you said it didn't work,
because I knew it *would* work because I knew that you had not,
through the o/s, prevented the file from being read, because I knew
you could not do that without Access failing to draw back the data to
display it. It was trivial. You pointed out permissions that you had
pulled from the file hierarchy, but I knew there was one permission
that you had not and could not pull or your app wouldn't work. I
won't get more specific so you don't fret about your student's google
searches - BUT AT LEAST YOU ARE NOW CONSIDERING IT POSSIBLE THAT
POTENTIAL MALEVOLENT USERS OF YOUR SYSTEM WILL KNOW HOW TO SEARCH THE
NEWSGROUPS/INTERNET - something Michka and I told you a lot earlier
was something that you had to take into consideration even for your
most clueless users


Yes, you're right. You did say that a long time back.

(hey, will that be a problem too - the way you've referred to the users of the system in past posts? <just kidding>).


LOL, I doubt it! Anyway, it was you who said they couldn't fight their way
out of wet paper bag!

You think I underestimate the users. I think I overestimate them. In my
dealings with most users I am constantly surprised at the paucity of their
knowledge and understanding of the machine they sit in front of all day.
I'll stop now and try to think of an occasion when the opposite has been
true. Nope. I can think of many times when users have done things which
demonstrate they have very poor understanding of computers. I can't think of
a time when they have surprised me by demonstrating a high level of
understanding. I won't bother going through a list of the umpteen times they
demonstrated their unable-to-fight-way-out-of-wet-paper-bag-ness. But there
have been plenty. So they can do a net search. Sure. See David's posts which
actually describe my attitude better than I can. I actually did a net
search. And found a few password crackers. Which of course is only relevant
if Access security is your only sort of defence. No doubt if I'd searched
longer and harder I'd have found all sorts of other stuff.

But we're into repetition here. We agree that Access security is flawed. You
would say severely and fatally? Actually when I say we agree what I mean is
that I take your word for it. I've never tried to crack Access security
itself. I believe you. I could chicken out and come up with some
mealy-mouthed 'but we have a difference of emphasis'. That's a bit of a
cop-out. I think the difference between me and you and Michka is actually a
lot more that a difference of emphasis. More like a different perspective. I
can't quite find the right words. But I don't think the difference between
our approaches is trivial. We agree on the final abilities of Access to be
secure, maybe. But disagree on...when it matters?

Probably not much more to discuss.

Thank you very much for you input.

Yours, Mike MacSween
Nov 12 '05 #67
Some good ideas there, thanks Wayne.

Yours, Mike

"Wayne Gillespie" <be*****@NObestfitsoftwareSPAM.com.au> wrote in message
news:l0********************************@4ax.com...
On Sat, 15 Nov 2003 06:00:05 -0000, "Mike MacSween" <mi******************@btinternet.com> wrote:
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
Obscurity is not security, and it is irresponsible and unrealistic toassume
this is good enough, for anyone.

<snip>

In this particular case:

1. Only those people who know about the database even know it exists. Theymay or may not tell their friends/relatives and so on.

2. At the moment the people who know about the database already have some
access to it.

3. They would need a desire to change the data without authority.

4. Theft of the data would not bring down the organisation. It may
constitute a breach of the data protection act, especially if it were widelypublished.

5. Unauthorised alteration of the existing data is more of a concern. It's adatabase for recording student marks. Students are the ones who might wantto alter marks. They have to get past NT security first. It's on a domain
they don't have access to, in the ordinary course of events. Of course,
people leave machines on etc. etc. We know that NT security can be
circumvented in various ways, often 'socially'. That is beyond my control.And of course the same caveat applies to all the college's data.

6. The academic process involves the discussion of each student's overall
year mark, then degree award, at a board of examiners. Usually 10-20 membersof the academic staff, most of whom will know the students' work fairly
well. Borderline students are always discussed. A student who had
significantly higher grades than was expected would be noticed, I think. Theparts of the course which contribute to the class of degree contain only 7modules. Some of those modules might only contain 1 or 2 assignments. Thereis a high probability that the member of staff who marked those assignmentswill be present and would remember that actually Jo Soap didn't get 80 forthat piece of work, but 55. And the marks are always recorded in paper formfirst, and that list of marks is present at exam board. That brief outlineof how the system is used is why I don't think that you have enough
information to comment on whether Access security (and anything else I mightuse) is 'good enough' for me. You don't know the context in which the
application is used. I do. No doubt there are plenty of 'ah, but what ifs'you have ready for me. I'd be interested to hear them.

7. I will present a precis of this thread to the management of the college,incorporating a summation of your, Peter's and others' comments. At that
point my professional duty is done. The college management can then make thedecision whether to abandon computerise record keeping, move to a databaseserver system, or continue with what I'm developing for them.

Yours, Mike MacSween


So we all agree that Access security is severly flawed.
You have mentioned several methods you can employ to make manipulation of

the data file more difficult for many users. In the scenario you have outlined above I would be inclined to build an interface which would make the data meaningless without the front end, and tightly control how the scores are entered in the front end. This would, to a large extent make the Access security flaws irrelevent.
In your scenario it would appear that in reality the score is the critical data piece that must be protected. Therefore I would design an interface specifically designed to protect the integrity of the score.

I would create a set of custom encryption / decryption functions eg -
'================================================= =
Function fEncryptScore(curScore As Currency, intRevNo As Integer) As String fEncryptScore = (((curScore * 10000) / 123) + 456)
fEncryptScore = fEncryptScore & intRevNo
End Function
'================================================= =
Function fUnencryptScore(strEncryptedScore As String) As Currency
Dim strCheckScore As String
strCheckScore = Left(strEncryptedScore, Len(strEncryptedScore) - 1)
fUnencryptScore = ((strCheckScore - 456) * 123) / 10000
End Function
'================================================= =
Use whatever calculation you like as long as it is reversable.

?fEncryptScore(75,1)
6553.560975609761

?fUnencryptScore(6553.560975609761)
75

Make sure the FE is an mde so the functions are not {easily} readable.

The score would be entered via an unbound textbox in a form and encrypted by your function and stored in it's encrypted form. Me.ScoreField = fEncryptScore(Me.ScoreEntry, Me.RevNo)

Once the score has been entered I would never allow the record to be edited. If the score needs to be changed I would add a new record and leave
the existing record intact. I would include a Revision No, EnteredBy (CurrentUser()), and TimeStamp (Now()) fields in the table containing the
score. Up the RevNo by 1 each time a new record is added for the student.

The score would only be displayed in the form in a disabled textbox using the function - =fUnencryptScore(Me.ScoreField)

If the datafile is opened directly the score will display a meaningless number. Without the encryption key, editing this number is a hit and miss affair.

If the record is edited using the frontend you will have a 2nd record added for the student. If you have suspisions about the score you could
verify with the CurrentUser entered in that record whether they did in fact change the score.
If they get real smart and change the score in the frontend and then open the table and copy the new score to original record and then delete the 2nd record, the last digit of the encrypted score (RevNo) will not match the rev no of the original record.
You could then write a loop to search for *suspicious* records (more than 1 record for student / RevNo does not match encrypted value)
Obviously this is a simplified example and your actual requirements will be far more complex than you have outlined, but my point is that the problem can be tackled from more than one direction.

I do NOT claim that any of the above provides 100% security or is better or worse than any other method, it is merely another layer of defence that can be employed which has no dependancy on Access Security (apart from getting the CurrentUser). I certainly would NOT recommend this method (or similar) for cc or other highly sensitive data and in your case, as Peter and David have stated previously you MUST fully discuss whatever method(s) you choose with the people responsible for the database and allow them the final decision.
Personally I wouldn't use Access for any secure purpose unless (ImportanceOfData <= (EffortToCrack /2)) But there are many, many purposes that meet this criteria.
Wayne Gillespie
Gosford NSW Australia

Nov 12 '05 #68
Thanks very much for you input everybody, especially Peter, Michael and
David.

I've been out of the house for 12 hours and came back to see umpteen
responses, so forgive me if I don't reply to each one.

I think we've all got a pretty good idea where we all stand on this, so I'm
not going to reiterate. Actually I don't really stand anywhere, I'm trying
to find out more. And I'll continue to find out more. After all, whether
Access security is worthless/good as far as it goes/superb is only part of
the story. I should know as much as I can about it anyway. Or at least
enough about it to make informed decisions and to help clients do the same.
I think I'm nearer that.

By the way Michael, I haven't really done any work for Chase Manhatten,
Amazon and ebay. That was, like, er, irony.

Anyway, I'm nice and relaxed now, been playing Gershwin all day. So time for
bed.

Thanks folks, Mike MacSween
Nov 12 '05 #69
TC

"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:su********************************@4ax.com...

Wayne,

On Sat, 15 Nov 2003 11:31:46 GMT, Wayne Gillespie
<be*****@NObestfitsoftwareSPAM.com.au> wrote in
comp.databases.ms-access:
I do NOT claim that any of the above provides 100% security or is better
or worse than any other method, it is merely another layer of defence
One that is completely bypassed by the student opening the backend and
copying the encrypted score from Tommy Braniac's student record to his
own, without ever worrying about the encryption.

Yes, yes, you can compensate for that too, but the point is that
adding more and more simple obfuscation layers
Why do you say that's "obfuscation"? Effective crypto has always required
not only making the information "undecipherable", but also, protecting it
against being changed. There are various well-known techniques for detecting
when data has been changed (eg. MACs). The use of those techniques is not
"security by obscurity".

TC

doesn't really do all
that much to improve security - all it really does is comfort the
owner of the data that they are protected. That is why security by
obscurity is always considered completely wrong-headed by the crypto
community.
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

Nov 12 '05 #70
dX********@bway.net.invalid (David W. Fenton) wrote in
<94***************************@24.168.128.78>:
Your position basically boils
down to the idea that the erection this level of barries is
worthless in all cases, and not worth the time or effort.


Oh, dear. My typist has a dirty mind.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #71

On Sat, 15 Nov 2003 23:25:11 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
One that is completely bypassed by the student opening the backend
and copying the encrypted score from Tommy Braniac's student
record to his own, without ever worrying about the encryption.
How, exactly, does the student know that he's getting a good score?


Perhaps it wasn't obvious. He went after Tommy Braniac's grades and
not Sam Slowpoke's. Get it?
And how long does it take him to identify a good student?
Oh, please. Um. Billy wants a better score. He's in a class with
Tommy Braniac and Sam Slowpoke. He says to himself, 'boy, I'd like
great grades like Tommy Braniac. But who's score should I copy.
Damn, I wish I was smart enough to work out which student's score in
my class I should clone if I want to get a score like Tommy
Braniac's'. God, this is tricky stuff.
You're assuming a linear encryption.
That's what was proposed. But actually, I'm not expecting any such
thing. I *was* assuming that each student's id was not used during
key composition for a one-way hash or encryption algorithm, but as I
pointed out, one could compensate for the copying problem after all.
You're also assuming the encrypted data can be understood
sufficiently to be interepreted by a human being well enough to
allow them to copy data.
Phht. I'm basing my comments on the suggestions made. It REALLY
DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.
Say, for instance that a grade was recorded in *two* tables,
or three, or four, or maybe five.

Obfuscation is obfuscation - period.
It's possible to make a system complex enough that it's not really
reasonably possible for a human being to be able to figure it out
just by looking at the raw data.
You're absolutely right, David. And of all the people in the world,
I'd have to say that students, as history has shown us, are the least
inclined and the least capable of ever cracking any system, and if
they were to attempt to crack some piece of software, the last, and I
mean very last thing we could expect them to target would be their own
schools grading system. <hopefully the sarcasm isn't missed>
Yes, yes, you can compensate for that too, but the point is that
adding more and more simple obfuscation layers doesn't really do
all that much to improve security - all it really does is comfort
the owner of the data that they are protected. That is why
security by obscurity is always considered completely wrong-headed
by the crypto community.


Any form of encryption is really just a sophisticated form of
security by obscurity, since if you have sufficient information
(the relevant decryption key(s)), you can retrieve the original
information.


That is a very weird way of looking at things. Security by obscurity
refers to the tendency people have to think that by making a system
tricky, and non-obvious, they are improving security. It does not
refer to the reality that any system that employs encryption probably
is doing so to protect (ie, keep secret, or hide) something. True
encryption works because it is not necessary to store or transmit
elements of the system that can make it vulnerable, while security by
obscurity refers to systems that leave all, or at least many of the
critical security aspects in the open, hidden only by a hopeful lack
of knowledge about where or how to find or interpret them. Most of
the things suggested in this thread fall into the later category
(renaming files, putting them in different places, using simple
encryption algorithms that are stored in the distributed app, etc).
What Wayne has described is simply the basic idea of
using a complex structure to store the information, a structure
that is not sufficient by itself to be interpretable, i.e., you
have to have the key to convert it to something
human-comprehensible.
And my point was to make clear that even non-human-comprehensible data
can be readily manipulated and used, with no knowledge whatsoever
about the encryption algorithm.

One of the easy ways to crack Access security involves just such an
approach. Without ever removing encryption on a jet database or
knowing anything about which encryption algorithm was used or what the
key was, or how it was implemented, you can write through the
encryption and desecure the file. Write through the encryption, you
gasp, without even understanding it! How so? By thinking about how
encryption works, and what it masks.
To me, the real way to protect this data is to have strong account
policies for the users who have permission to edit the data, such
as locking the workstation after a small inactivity period, and
requiring strong passwords for those users, and also giving only
extremely limited access to the server on which the data is stored
(including limiting that access to only a small number of
workstations, for instance), and, of course, limiting access to the
share where the data MDB is located only to those users who should
be editing it.
Well, I would agree with all these measures. Of course they should be
implemented. You are not protecting the system very well from abuse
by authorized users with these tactics, but you are making inroads in
preventing other types of attacks. These approaches are meaningful.
But when you get into some of the other ideas, I think things get a
little weak.
Personally, I think all of that is much more important than mucking
around with Access to try to make it harder to understand the raw
data. If they can't get to that data in the first place, then
there's no risk from the students.
Yes.
Spending lots of time making the data storage structure
non-transparent is only worth it if you consider the risk to be
reasonably high that someone will be able to break through all the
network layers to get access to the raw data file.


True. But remember that your raw Access data file WILL ALWAYS BE
AVAILABLE IN FULL to any valid users/systems. I know you mentioned it
above, but it should be stressed that you can never, with Access,
prevent access to the raw data file, whereas with a true server rdbms,
you can indeed protect the raw file (again, this doesn;t mean that o/s
vulnerabilities don't exist there too, but it does mean that the raw
data file doesn't need to be exposed for the rdbms to use it, as it in
fact must be for Access).
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #72

On Sun, 16 Nov 2003 11:27:05 +1200, "TC" <a@b.c.d> wrote in
comp.databases.ms-access:
Why do you say that's "obfuscation"?
Please be clearer. I was referring to using a simply translation
algorithm which wasn't keyed off anything student-specific. That is
obfuscation alone.
Effective crypto has always required
not only making the information "undecipherable", but also, protecting it
against being changed. There are various well-known techniques for detecting
when data has been changed (eg. MACs). The use of those techniques is not
"security by obscurity".


Very true, of course, but the suggestion made involved no such
techniques. There was a suggestion to log changes to scores, but
logging activity is not in any way related to signing values, using
checksum, sand the like.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #73

David,

On Sat, 15 Nov 2003 23:04:28 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
What Mike is looking for is *not* security. He's simply looking to
make it harder for the casual user to much around with things that
aren't their business.


I am in full agreement with this, based upon what Mike's said. I
don't know, though, whether he would agree with you.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #74

On Sat, 15 Nov 2003 22:49:07 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
pm*****@pksolutions.com (Peter Miller) wrote in
<t0********************************@4ax.com>:
I honestly and sincerely
believe that telling clients that Access security (and that which
you can build on your own on top of it) is anything other than
terribly weak and flawed is doing them a disservice.
But with Access alone and no outside expertise, you can't break the
security.


Actually, you can.
For someone to do so, they'd need to know a number of things:

1. that the application is secured in any way at all (most end
users never need to know anything of the sort).
Oh, yes, you have a point here. If they don't know that there's
information in the system that they want, then they wouldn't target
it. Good point. Of course, if they knew such information existed
(and really, I thought we were all assuming here that they did), then
is it really such a leap (really!?!) to imaging that the reason they
can't get to what they want might, possibly, and I'm going out on a
limb here, have something to do with security?
2. that there exists something called "Access security".
And perhaps, since they're using Access, it might be, um, like, maybe
ACCESS SECURITY???
3. that this security is crackable.
And, despite all the non-crackable security implementations out there,
perhaps, just perhaps this one, unlike all the others, might be
crackable?
4. that the cracks for this security are readily available.
And if I dod a quick google search, I might find....
Then they'd need the expertise to use those cracks.
....some freaking expertise!

I've never looked at these solutions (I have no interest or need),
so I don't know if they are standalone executables or simple VBA
code, or if they utilize any kind of encryption cracking libraries
or what. Nor do I know what you get from these, a fully unsecured
file or the information necessary to unsecure it.
I haven't done much of look at such available software either, but I
don't need to. I know the flaws. I know how trivial they are to
exploit. I know that even a half-assed stupid implementation of a
hack on just one of these flaws would render Access security rather
useless. What more do I need to know about particular crackware out
there aimed at Access.
But they'd need certain skills to use such a utility unless it's a
"run an executable, point it at the file you want unsecured and
supply the filename for the unsecured version." If that's the case,
then, yes, it could be done by someone who knows the four pieces of
information above.
Wow. What sort of utility do you think these punks would sell? I
mean, OBVIOUSLY its point-and-click stuff, no? What other
complications could have been added? I can't imagine any.
So, you're only worrying about the people of ill will who have a
little bit of knowledge.
And we certainly don't need to worry about anyone like that, now, do
we?
With Mike's additional techniques, this person would also need to
know:

1. that the data files are not stored in the front end.
Crack the fe. See that it contains nothing data-wise. Move on to the
backend. Sounds pretty simple to me.
2. how to locate the back end data file in a secured front end
The front-end is cracked. Its connection to the backend is now
obvious.
3. how to navigate to the back end.
The front-end details that.
Those are trivialities to us, but basic conceptual difficulties
that could stop certain kinds of people in their tracks.
How stupid do you really think people are? Obviously more so than I
would think.
But I still think that protecting you from all the rest of them is,
in fact, worth doing.

You seem to think that it is not.
No. I just see a lot of confusion on this topic, and a lot of
under-estimating.
And that's why I have a problem with these blanket condemnations of
the kinds of things Mike is doing. Your position basically boils
down to the idea that the erection this level of barries is
worthless in all cases, and not worth the time or effort.


Not at all. I think that the better techniques are worth pursuing, as
long as one is quite clear about their faults, and the weaker ones
are, yes, not only a complete waste of time but also simply add to the
creator and users sense of perceived security while providing no
additional benefit (in other words, they actual decrease security by
reducing concerns in an unjustified manner).
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #75

On Sat, 15 Nov 2003 23:02:33 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
There is no circumstance in which security can be considered that
does not need to be defined as "sufficient for the circumstances
we've foreseen and within the budget we've got and within the
estimation of potential risk that we foresee at the present time."
That is the definition that applies to security considerations of
any organization, any application, any database.
Agreed. If this statement is understood fully. I suggest that in
this case, and based upon Mike's belief in the viability of some of
the ideas presented, that this statement may need further
clarification.
You seem to be arguing that the only worthwhile protection is "more
than sufficient for the circumstances we've foreseen, etc."


No, but its not a bad goal. Better to err on the side of better
protecting your system than you intended.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #76

On Sat, 15 Nov 2003 23:52:47 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
Even doing all of that, someone in the office of an authorized user
who left their PC logged on could then get into the data and muck
around with it. But that's a vulnerability of *any* database
application, so I don't think it's really valid to put the burden
there on Access alone.
Depends what you mean by 'muck around'. If you mean that any such
system may allow a malevolent user to mess around with the front-end,
then that's more or less true, but, and I know you know this but it
should be stressed, the reason why mucking around with such a system
when Access was used for storing the data is that if you let such a
user use your frontend, you have also exposed to them the raw backend
data file - a terrible reality that is not at all true of any server
based rdbms.
Now, the vulnerability is not exactly the same.

With an Access back end, you don't need the application or an
authorized login to manipulate the data, as you would with, say, a
SQL Server back end.
Don't you hate it when you type a response inline, then see that the
poster was headed in that same direction? I do.

But a slight difference may exist between where you're heading and
what I'm saying. Sure, The user doesn't need a valid login to mess
with Access, while they would for sql server, but the more important
difference is that they can't mess with the actual sql server raw
file, while they get the whole shebang with Access.
But to steal or alter the MDB file if the network and NT security
infrastructure was properly restricted, these things would have to
happen:

1. an authorized user has to leave her machine logged on and
unattended.

2a. the network policy must have no timeouts that will log off or
lock the workstation after a short period of inactivity, OR

2b. the hacker must get access to the unattended logged-on machine
before the timeout expires.

3. the hacker must know what application is used for storing the
information he wants to hack.

4. the hacker must know how to look at that application and figure
out it's stored in an Access MDB.

5. the hacker must know how to figure out how to located that MDB
file from the information available in the front end MDB.

6. the hacker must know how to bypass any restrictions on the front
end MDB that protect the information about the location of the back
end data file.

7. having located the back end, the hacker must know how to gain
access to the Jet-secured back end.

8. having gained access, the hacker will need to examine the data
structure and figure out how to change the data without being
detected.

9. the hacker must do all of this without being discovered working
at the PC of the absent office worker.

How likely are all of these things?

Possible?

Absolutely.

But if the machines that are authorized are not in locations that
students have access to and have appropriate policies applied, then
the window is very narrow.
I've been meaning to ask Mike whether any of these users systems also
have internet access. Not a big deal, but it would be terribly
interesting if the answer were yes.

Most of the tasks above take little time. It is true though that
doing them all with no initial knowledge of the system is unlikely.
However, who says it would be an all-in-one type deal. Why wouldn't
the attacker just get the fe the first time, and get no further, then
crack it at home, realize what they were looking for, and come back
for the backend?
Now, it's possible that a hacker could just ship a copy of the file
of to a different location, then at her leisure, hack the data
structure and figure out how to undetectably alter the back end,
then they'd have to have a moment of opportunity to be back at an
unattended, logged-on workstation to munge the data.
Damn it. You did it again!
There are a whole lot of ifs here, a whole lot of knowledge
necessary, and a whole lot of opportunities needed.

Yes, it could all come together, but it is not something that could
happen, I believe, without planning and luck *if* the working
environment is appropriately limited, i.e., if the locations from
which the data can be accessed are severely limited and controlled.

What you do in Access to make things less obvious only add to the
amount of time
and increase the amount of interest
it takes to munge the data once the opportunity to
work at the unattended workstation has presented itself. So, to me,
the first line of defense is actually making sure that unattended
logged-on workstations are the exception, and that the likely
hackers are not given access to those machines, unattended or not.
And password policies have to be very strong and the network
infrastructure designed to be as narrowly available as possible.
Sure.
But I still think the things you *can* do with Access itself are
worth doing, as people do leave their workstations unattended, and
unauthorized people can sit down at those unattended workstations.
Putting up a few more barriers in Access simply increases the
amount of time needed to break the system, and I think that's worth
it, if one assumes that someone gets through all the policies and
procedures and mechanisms put in place to reduce that chance that
someone gets that far in the first place.


Fair enough, but I think that Access security, like any weak security
system, wastes developers time and creates undue hazards because
people first come to it with the assumption that it must be basically
workable, even though they know that all systems are eventually
crackable. The more weak security features you add to a system, the
more likely (not less) that system is to be compromised in the
long-term - that's my view. You may not agree with me, but I think
the more time you spend thinking about these sorts of things, the more
likely you are to see my point, and even possibly agree with me.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #77
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:ub********************************@4ax.com...
Oh, please. Um. Billy wants a better score. He's in a class with
Tommy Braniac and Sam Slowpoke.


Hey, how come you know the names of my students? Have you cracked my
security? Dang!

Mike
Nov 12 '05 #78
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:ub********************************@4ax.com...
Phht. I'm basing my comments on the suggestions made. It REALLY
DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.


Actually I'm quite interested in Wayne's idea of encrypting key data in the
back end. I don't think your statement above is true. I agree with your
comment elsewhere that if a naive user tries to gain access to a system that
is written in Microsoft Access and they can't, that they'll then put 2 and 2
together and figure that the thing that's stopping them is called security
and do a net search for 'Access Security'. Which does reveal some password
cracking things. I didn't search long, but it actually threw up a great deal
of other totally unrelated stuff. And the things I found all needed money to
be spent. Trivial amounts of money, but enough to deter many or most of the
people I have in mind now. And with an Access system they are the only
people I can worry about. I can't worry about you, Michka, Stuart McClure,
Kevin Mitnick et al. Well, I can worry, but I won't. C'est La Computing Vie.

But I do think that for the vast majority of computer users, the system as
described above would be uncrackable. Think what they've got to get past:

1. They need access to a machine.
2. NT security.
3. They need to find out about Access. What a FE and BE is.
4. Where the BE is.
5. They need to get past Access security.
6. They then see a raw data file, with data that doesn't make sense, to
them.

Let's think about that data file. The tables are well named, but in
hungarian - tblStudents etc. The fields are Marks, FirstName etc. But the
relationships are complex. They aren't going to find a table that says:

Sam Slowpoke, 1st Essay, 25

Because of course its tblStudents tblCourses trelStudentCourse tblModule
tblAssignment trelStudentCourseAssignment tblMark. Or something like that.

You and I won't think the relationships are complex, but a non database
person will. If those data were encrypted, perhaps even all the data, that
would make it all extremely non intuitive. Of course I could go one step
further and not store relationships in the back end. I know some people
don't.

A simple one would be ROT13 on students names. That isn't intuitive for most
users. And I have to say you have far too high an opinion of most users if
you think it is. ROT13 or something better on table and field names too
perhaps. Now Sam Slowpoke is looking at some 'tables' (which he's only just
learned about in Access For Slowpokes) and he can figure out that some of
this must be marks, and names and stuff, but sheeesh, what?

I really don't think that's easy or intuitive. To get past steps 1-6 and
then the rest. It needs a lot of determination, knowledge and intelligence
and the desire to actually do the thing (and the willingness to be caught
doing it and risk getting 0 for everything).

All this I guess comes under the heading of security by obscurity. Which may
or may not be meaningful security. Which I think is the difference of
opinion here. The meaning of 'meaningful security'.

Yours, Mike MacSween
Nov 12 '05 #79
pm*****@pksolutions.com (Peter Miller) wrote in
<ub********************************@4ax.com>:
On Sat, 15 Nov 2003 23:25:11 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
One that is completely bypassed by the student opening the
backend and copying the encrypted score from Tommy Braniac's
student record to his own, without ever worrying about the
encryption.
How, exactly, does the student know that he's getting a good
score?


Perhaps it wasn't obvious. He went after Tommy Braniac's grades
and not Sam Slowpoke's. Get it?


So, you're saying that the student name is stored in the grade
record? Or that the student follows the foreign keys to the
students table?
And how long does it take him to identify a good student?


Oh, please. Um. Billy wants a better score. He's in a class
with Tommy Braniac and Sam Slowpoke. He says to himself, 'boy,
I'd like great grades like Tommy Braniac. But who's score should
I copy. Damn, I wish I was smart enough to work out which
student's score in my class I should clone if I want to get a
score like Tommy Braniac's'. God, this is tricky stuff.


It would be if the information you assume is blazingly obvious is
not stored in a format that is human readable.

First off, even with no encoding of names or foreign keys, a grade
is going to be at least 3 tables away from the student name:

tblGrades ->
tblAssignments ->
tblClasses ->
tblClassesStudents ->
tblStudents

The student doing the hacking is going to have to understand
database structure and be able to read and interpret the schema.

The student will need time to either write a query to display the
relevant data or follow the foreign keys manually.
You're assuming a linear encryption.


That's what was proposed. . . .


That's what was given as an initial example, with the advice at the
end that you'd probably want to do something beyond that.
. . . But actually, I'm not expecting any
such thing. I *was* assuming that each student's id was not used
during key composition for a one-way hash or encryption algorithm,
but as I pointed out, one could compensate for the copying problem
after all.
But you're assuming a couple of things:

1. the student doing the hacking is smart enough to understand a
database schema and figure out which grade records to copy. This
includes not just tracing back to the student, but also to the
appropriate classes and assignments.

2. the student names are unencoded plain text.

3. the foreign keys are not stored in an encoded format.

4. the student has sufficient time given the opportunity for
hacking to figure out all of these things.

Assuming proper securing of access to the back end via network
architecture and NT security, this means the student manages to do
all of this sitting at a previously unattended logged-on PC in the
office of someone who is authorized to edit the data.
You're also assuming the encrypted data can be understood
sufficiently to be interepreted by a human being well enough to
allow them to copy data.


Phht. I'm basing my comments on the suggestions made. It REALLY
DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.


But Wayne was not proposing using exactly the system he described.
He clearly stated that this was a simple example given as a
starting point.

Did you read to the end of the post?
Say, for instance that a grade was recorded in *two* tables,


or three, or four, or maybe five.

Obfuscation is obfuscation - period.


Encryption is a form of obfuscation, just one that is accepted as
OK because strong encryption systems are so hard to crack.
It's possible to make a system complex enough that it's not
really reasonably possible for a human being to be able to figure
it out just by looking at the raw data.


You're absolutely right, David. And of all the people in the
world, I'd have to say that students, as history has shown us, are
the least inclined and the least capable of ever cracking any
system, and if they were to attempt to crack some piece of
software, the last, and I mean very last thing we could expect
them to target would be their own schools grading system.
<hopefully the sarcasm isn't missed>


You're assuming sufficient opportunity to do the hacking at
leisure. In another post I've outlined exactly how you limit that
opportunity via network architecture and NT security. In those
cases, these additional steps, which are crackable given infinite
time, become barriers that are unlikely to be surmountable in the
time available to an opportunistic hacker.
Yes, yes, you can compensate for that too, but the point is that
adding more and more simple obfuscation layers doesn't really do
all that much to improve security - all it really does is
comfort the owner of the data that they are protected. That is
why security by obscurity is always considered completely
wrong-headed by the crypto community.


Any form of encryption is really just a sophisticated form of
security by obscurity, since if you have sufficient information
(the relevant decryption key(s)), you can retrieve the original
information.


That is a very weird way of looking at things. Security by
obscurity refers to the tendency people have to think that by
making a system tricky, and non-obvious, they are improving
security. . . .


Well, putting packages under the seat in your automobile and
locking the door is a form of security by obfuscation. Anyone who
gets into the automobile may very well be smart enough to search
under the seats and find your iPod or whatever expensive item
you've hidden. But the point is by hiding it you tempt fewer people
to break in in the first place.
. . . It does not refer to the reality that any system that
employs encryption probably is doing so to protect (ie, keep
secret, or hide) something. True encryption works because it is
not necessary to store or transmit elements of the system that can
make it vulnerable, while security by obscurity refers to systems
that leave all, or at least many of the critical security aspects
in the open, hidden only by a hopeful lack of knowledge about
where or how to find or interpret them. Most of the things
suggested in this thread fall into the later category (renaming
files, putting them in different places, using simple encryption
algorithms that are stored in the distributed app, etc).
???

Exactly where in an MDE is the algorithm stored? Or are you
proposing someone decompile the MDE to reverse engineer the
algorithm?

Secondly, you're assuming that these things are true:

1. the hacker knows there is an encoding algorithm in place.

2. the hacker knows which data the algorithm is based on.

3. the hacker knows that the algorithm is encoded in the front end
MDE.

4. the hacker knows that MDEs can be decompiled by hand and,
perhaps, used to figure out the exact algorithm.

5. the hacker has the time to take the MDE and decompile it and
figure out the algorithm and then has the time to decode the data,
and last of all, has the time to change the data.

Assuming a situation where only certain PCs in an administrative
office logged on as authorized users have access to the data, the
possibility of a student getting through all of those barriers is
vanishingly small, unless the student is a budding 007, seems to
me.
What Wayne has described is simply the basic idea of
using a complex structure to store the information, a structure
that is not sufficient by itself to be interpretable, i.e., you
have to have the key to convert it to something
human-comprehensible.


And my point was to make clear that even non-human-comprehensible
data can be readily manipulated and used, with no knowledge
whatsoever about the encryption algorithm.


You were assuming that:

1. the data that points to the grade record and identifies the
student it belongs to is going to be located by the hacker AND

2. when that information is found, it is stored in as form that is
recognizable as the particular student desired by the hacker.
One of the easy ways to crack Access security involves just such
an approach. Without ever removing encryption on a jet database
or knowing anything about which encryption algorithm was used or
what the key was, or how it was implemented, you can write through
the encryption and desecure the file. Write through the
encryption, you gasp, without even understanding it! How so? By
thinking about how encryption works, and what it masks.
But in this case it would require understanding a structure that is
not completely obvious or known in advance and having the time to
do the work to figure it out and subvert it.
To me, the real way to protect this data is to have strong
account policies for the users who have permission to edit the
data, such as locking the workstation after a small inactivity
period, and requiring strong passwords for those users, and also
giving only extremely limited access to the server on which the
data is stored (including limiting that access to only a small
number of workstations, for instance), and, of course, limiting
access to the share where the data MDB is located only to those
users who should be editing it.


Well, I would agree with all these measures. Of course they
should be implemented. You are not protecting the system very
well from abuse by authorized users with these tactics, but you
are making inroads in preventing other types of attacks. These
approaches are meaningful. But when you get into some of the other
ideas, I think things get a little weak.


Well, I don't believe it's really possible to protect data from
authorized users -- you have to trust them, since they can always
input erroneous or invented data through authorized methods that
would be just as damaging as data changed by a hacker. This is the
case even with a secured server-based back end.

So, on that level, I see little difference between the two systems.

The only additional vulnerability with Jet is that the authorized
user has plenty of opportunity to hack the back end. But there's
little reason for the authorized user to do that, except to hide
who made the changes (assuming that authorized methods record who
made the changes). That's possibly significant information, but if
the data's wrong, it's wrong, no matter who made the change. If the
data tables require a user be recorded as having updated it, then
the unauthorized data change would simply be pointing at the wrong
person, who would deny making the change.

Either way, you don't know that it's wrong data *structurally* --
you can only know it by knowing what data *should* be, and any
system is vulnerable to that problem whether through authorized or
unauthorized methods.

And Mike has said that in the case of the app he's working on,
there's a paper trail that documents how the data got entered, so
the paper trail would also have to be altered in order for the
authorized user to get away with it.
Personally, I think all of that is much more important than
mucking around with Access to try to make it harder to understand
the raw data. If they can't get to that data in the first place,
then there's no risk from the students.


Yes.
Spending lots of time making the data storage structure
non-transparent is only worth it if you consider the risk to be
reasonably high that someone will be able to break through all
the network layers to get access to the raw data file.


True. But remember that your raw Access data file WILL ALWAYS BE
AVAILABLE IN FULL to any valid users/systems. . . .


Yes, and that's the basis for my statement that the most likely
candidates for wanting to hack the data are not going to be able to
get access to it.
. . . I know you
mentioned it above, but it should be stressed that you can never,
with Access, prevent access to the raw data file, whereas with a
true server rdbms, you can indeed protect the raw file (again,
this doesn;t mean that o/s vulnerabilities don't exist there too,
but it does mean that the raw data file doesn't need to be exposed
for the rdbms to use it, as it in fact must be for Access).


I've dealt with this issue above.

I believe you must trust your authorized users while having audit
trails in place. That is, a paper trail.

It's like with the electronic voting systems. You've got to have
some non-electronic method of verifying that the electronic data is
correct. That's how you protect yourself from the authorized users.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #80
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:
I really don't think that's easy or intuitive. To get past steps
1-6 and then the rest. It needs a lot of determination, knowledge
and intelligence and the desire to actually do the thing (and the
willingness to be caught doing it and risk getting 0 for
everything).


And it also requires significant time.

If the network is secured properly, no student will have that time
available to them.

You'll still be vulnerable to authorized users attempting to munge
the data, but those users will then have to get past the structural
issues in the back end, as you've said. And my bet is that,
ROT13-encoded or not, most of your authorized users won't be able
to figure out which record in the test score table to copy.

And why would they need to?

They could just go in and enter the score incorrectly the first
time.

Why they'd do that, I can't say.

Assuming that instructors maintain their own gradebooks independent
of the database application, I think it's pretty unlikely that an
administrative worker could significantly alter the grades of a
particular student (e.g., after being bribed, for instance) without
the instructor noticing. At NYU, at least, instructors have to sign
final grade sheets, and no instructor is going to sign that and
turn it in to the Registrar without carefully checking that the
grades are correct.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #81
pm*****@pksolutions.com (Peter Miller) wrote in
<k3********************************@4ax.com>:
On Sat, 15 Nov 2003 22:49:07 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
pm*****@pksolutions.com (Peter Miller) wrote in
<t0********************************@4ax.com>:
I honestly and sincerely
believe that telling clients that Access security (and that
which you can build on your own on top of it) is anything other
than terribly weak and flawed is doing them a disservice.
But with Access alone and no outside expertise, you can't break
the security.


Actually, you can.


By "outside expertise" I meant knowledge that is not included in
the Access application package itself.

In other words, you can't figure out how to beak Access security
with the Access help file.

Now, if you're trained in encryption and fully understand the way
Access/Jet security works, you could probably figure it out, given
sufficient time (and it might be a relatively trivial amount of
time).

So, I guess it's not "outside expertise" for the person who has the
expertise already.

But a person who doesn't know Access and doesn't know VBA and
doesn't know encryption technologies, they'd have find the
information somewhere outside.

Which is what I meant by my statement.
For someone to do so, they'd need to know a number of things:

1. that the application is secured in any way at all (most end
users never need to know anything of the sort).


Oh, yes, you have a point here. If they don't know that there's
information in the system that they want, then they wouldn't
target it. Good point. Of course, if they knew such information
existed (and really, I thought we were all assuming here that they
did), then is it really such a leap (really!?!) to imaging that
the reason they can't get to what they want might, possibly, and
I'm going out on a limb here, have something to do with security?


I don't know what the likely hackers in the user population
involved know and don't know. All I do know is that they'd have to
think through a number of things that most users of such
applications never give any thought to.

And, of course, it's not even the users who are the likely hackers
here, but students, who would not have the advantage of knowing the
way the UI works as a starting point for working out the structure
of the back end.
2. that there exists something called "Access security".


And perhaps, since they're using Access, it might be, um, like,
maybe ACCESS SECURITY???


You're assuming a lot that most end users are not going to figure
out.
3. that this security is crackable.


And, despite all the non-crackable security implementations out
there, perhaps, just perhaps this one, unlike all the others,
might be crackable?


You're assuming that have knowledge of the facts and history of
security systems and attacks on them.
4. that the cracks for this security are readily available.


And if I dod a quick google search, I might find....


If you know what to look for -- see steps 1-3.
Then they'd need the expertise to use those cracks.


...some freaking expertise!


Tell me what expertise is needed -- I really have no idea.
I've never looked at these solutions (I have no interest or
need), so I don't know if they are standalone executables or
simple VBA code, or if they utilize any kind of encryption
cracking libraries or what. Nor do I know what you get from
these, a fully unsecured file or the information necessary to
unsecure it.


I haven't done much of look at such available software either, but
I don't need to. I know the flaws. I know how trivial they are
to exploit. I know that even a half-assed stupid implementation
of a hack on just one of these flaws would render Access security
rather useless. What more do I need to know about particular
crackware out there aimed at Access.


A hack that involves writing VBA code will stop the vast majority
of your potential hackers right there -- most people don't know how
to write code.
But they'd need certain skills to use such a utility unless it's
a "run an executable, point it at the file you want unsecured and
supply the filename for the unsecured version." If that's the
case, then, yes, it could be done by someone who knows the four
pieces of information above.


Wow. What sort of utility do you think these punks would sell? I
mean, OBVIOUSLY its point-and-click stuff, no? . . .


Is it? I really don't know.
. . . What other
complications could have been added? I can't imagine any.


Peter, I don't know whether it's point and click products or
whether it's a recipe for writing VBA code.

Even with point and click, I know plenty of people who are stymied
by a SAVE AS dialog box -- I kid you not.
So, you're only worrying about the people of ill will who have a
little bit of knowledge.


And we certainly don't need to worry about anyone like that, now,
do we?


Well, the people with this knowledge need to have the opportunity.
Lots of students will have this knowledge, but given proper network
admininstration, won't have access to use it.

Authorized users are probably much less likely to have this
knowledge, but they're also much less likely to have any reason to
*want* to hack the data. But if they wanted to, they could just as
easily enter incorrect data through authorized methods as by going
to all the trouble to hack the back end data file.

Either way, with paper audit systems in place, it could potentially
be caught, as long as someone is checking the paper trail against
the electronic record, and as long as the authorized user has been
unable to alter the paper records as well.
With Mike's additional techniques, this person would also need to
know:

1. that the data files are not stored in the front end.


Crack the fe. See that it contains nothing data-wise. Move on to
the backend. Sounds pretty simple to me.


You're assuming someone knows about front ends and knows that they
need to crack it.
2. how to locate the back end data file in a secured front end


The front-end is cracked. Its connection to the backend is now
obvious.


You're assuming the hacker has the knowledge already. I'm only
outlining what knowledge is, in fact, essential to get the job
done. You're simply waving your hand and saying "everybody knows
that" when, in fact, everybody does *not* know that. We get people
in this newsgroup all the time who don't know it, and they are
people who are already working with Access.
3. how to navigate to the back end.


The front-end details that.


Assuming they have the concepts of front end/back end and
application vs. data store to work with in the first place.

Most of my clients who use my Access applications all the time have
never reached this level of conceptualization about their
applications. Otherwise, I wouldn't have to hold their hands for
the reconnect operation each time I send them a front end update.
Those are trivialities to us, but basic conceptual difficulties
that could stop certain kinds of people in their tracks.


How stupid do you really think people are? Obviously more so than
I would think.


I'm not saying that 99.999% of the population does not know this.

I'm only saying that the population that is a danger is limited to
the people who know these things. That is some percentage less than
100% of computer users. I am certain that is is far less than 50%
of computer users.

In terms of who is likely to want to hack a database that stores
student grades, I think your likely hacker population is students,
and probably a lot more of them have the necessary knowledge than
the general computer-using population. But if your network is
properly designed and maintained, they won't have much opportunity
to use their knowledge, or to even find out that the application
that stores grades is an Access application.

Yes, if they get the opportunity to sit down at a logged-on PC in
the office of someone authorized to use the application, they could
then use their knowledge to get the information.

But they'd have to have that opportunity to do so.

And it wouldn't be something that could be done in 5 minutes
because the student wouldn't know what they are hacking until they
sat down.

Yes, I assume proper administrative and network policies in these
administrative offices, and that the PCs that have access to the
database application are not in places readily accessible to
students. But that's simply a no-brainer, isn't it? Maybe it's not,
but if we take as a given that students don't have ready access to
the application, except by taking advantage of an oversight by an
authorized user, then each little barrier adds to the amount of
time it takes to munge the data, and is, I believe, helpful.
But I still think that protecting you from all the rest of them
is, in fact, worth doing.

You seem to think that it is not.


No. I just see a lot of confusion on this topic, and a lot of
under-estimating.


I see you over-estimating capabilities of the general user
population and assuming wide-open access. And it seems to me you're
not accounting for the purpose of this application, storing student
grades, when evaluating the risk. Students are the risky
population, as authorized employees have no motivation for hacking
the data, and students shouldn't have access to the database in the
first place. Also, Mike has mentioned that there are paper records
from which the the data entry is done, so there's always an audit
trail. A student would be unlikely to be able to alter the paper
trail as well as munging the data. It's also unlikely that even an
authorized employee would be able to completely alter the audit
trail.

Think of how this works:

1. teacher grades papers.

2. teacher records grades in gradebook.

3. teacher records grades on grade sheet for turning in to the
administrative workers for data entry.

4. teacher makes photocopy of grade sheet for files.

5. data entry person enters grades and files grade sheet turned in
by student.

6. data entry person prints out data entry summary and files that
with original grade sheet.

Now, let's assume a student slips into someone's office and munges
the grades in the database.

At the end of the semester, the instructor calculates a grade and
turns in a final grade on a grade sheet.

This final grade sheet does not match up with the final grade
calculated by the database application *or* (much more likely), the
database calculation is never really used to calculate a final
grade in the first place -- the instructor has final say on the
exact grade awarded based on the instructor's records.

Even if the change is made by an authorized user (say, one who has
been bribed by a student), the final grade is still not really
altered.

And the authorized hacker would still have to alter the filed grade
sheets and reprint the data entry summary. Assuming the Access
application gets its time stamps for reports from a server and not
from the local workstation, there's no way for the authorized
hacker to produce a printout that has a valid time/date stamp,
except by spending time scanning and editing via graphics software
the printout. And the copy of the original grade sheet that is in
the instructor's files will still not be alterable, nor the
instructor's gradebook.

And if the people doing the data entry are not allowed to print the
data entry summaries themselves, then that person couldn't falsify
the record at all, except by Photoshopping it.

In other words, there are too many pieces of paper around that are
too hard to alter that would show up the inconsistency.

And it only matters in the first place if the database application
and not the instructor is calculating the final grade, which is
never the case in any academic institution I've ever seen.

So, I think that, as Mike has already argued, you are not fully
accounting for the actual reality of the application involved, what
it's used for, and what policies are in place.

Maybe Mike's department does not have policies like these in place,
with good network infrastructure, heavily restricted access, proper
logoff timeouts, strong password requirements, multiple paper audit
trails, distribution of work process between multiple workers and
time stamps taken from central servers and so forth.

If they don't, they should surely be putting those policies into
effect before spending time on encrypting the grades in the back
end.

But once the administrative policy is tightened in those ways, yes,
you can get additional benefit from erecting a few more barriers to
anyone who gets past the administrative barriers.
And that's why I have a problem with these blanket condemnations
of the kinds of things Mike is doing. Your position basically
boils down to the idea that the erection this level of barries is
worthless in all cases, and not worth the time or effort.


Not at all. I think that the better techniques are worth
pursuing, as long as one is quite clear about their faults, and
the weaker ones are, yes, not only a complete waste of time but
also simply add to the creator and users sense of perceived
security while providing no additional benefit (in other words,
they actual decrease security by reducing concerns in an
unjustified manner).


I disagree vehemently.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #82
pm*****@pksolutions.com (Peter Miller) wrote in
<qp********************************@4ax.com>:
On Sat, 15 Nov 2003 23:02:33 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
There is no circumstance in which security can be considered that
does not need to be defined as "sufficient for the circumstances
we've foreseen and within the budget we've got and within the
estimation of potential risk that we foresee at the present
time." That is the definition that applies to security
considerations of any organization, any application, any
database.


Agreed. If this statement is understood fully. I suggest that in
this case, and based upon Mike's belief in the viability of some
of the ideas presented, that this statement may need further
clarification.
You seem to be arguing that the only worthwhile protection is
"more than sufficient for the circumstances we've foreseen, etc."


No, but its not a bad goal. Better to err on the side of better
protecting your system than you intended.


After posting that I re-read it and gave it some thought.

Personally I think of "sufficient" as meaning "protection that is a
somewhat stronger than the likely threat we consider our app to be
up against." That is, you consider the likely strongest threat and
then build your system to withstand that and a little bit more.
It's only that kind of system that I'd consider "sufficient," as
you need some margin of safety for the unforeseen.

How big a margin will be up to the particular client to decide,
considering all the factors, likely risk, cost/benefit, etc.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #83
"David W. Fenton" <dX********@bway.net.invalid> wrote in message

Complete sense. Very well put David.

Yours, Mike MacSween
Nov 12 '05 #84
pm*****@pksolutions.com (Peter Miller) wrote in
<jv********************************@4ax.com>:
On Sat, 15 Nov 2003 23:52:47 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
Even doing all of that, someone in the office of an authorized
user who left their PC logged on could then get into the data and
muck around with it. But that's a vulnerability of *any* database
application, so I don't think it's really valid to put the burden
there on Access alone.
Depends what you mean by 'muck around'. If you mean that any such
system may allow a malevolent user to mess around with the
front-end, then that's more or less true, but, and I know you know
this but it should be stressed, the reason why mucking around with
such a system when Access was used for storing the data is that if
you let such a user use your frontend, you have also exposed to
them the raw backend data file - a terrible reality that is not at
all true of any server based rdbms.


But to me that's a difference that makes no difference.

Accounts embezzle all the time, not by entering invalid data, but
by entering unreal data that balances out in the accounting system.

The same thing can be done with any database application through
authorized methods. If the data entry clerk has been bribed to
enter an A for the student who has a C listed on the grade sheet,
it really doesn't matter how secure the back end data store happens
to be.
Now, the vulnerability is not exactly the same.

With an Access back end, you don't need the application or an
authorized login to manipulate the data, as you would with, say,
a SQL Server back end.


Don't you hate it when you type a response inline, then see that
the poster was headed in that same direction? I do.


Well, at least you said that I already knew it!
But a slight difference may exist between where you're heading and
what I'm saying. Sure, The user doesn't need a valid login to
mess with Access, while they would for sql server, but the more
important difference is that they can't mess with the actual sql
server raw file, while they get the whole shebang with Access.
And I think this is a difference that makes no difference because
the authorized user doesn't *need* to muck with the back end. They
can enter incorrect data via authorized means.
But to steal or alter the MDB file if the network and NT security
infrastructure was properly restricted, these things would have
to happen:

1. an authorized user has to leave her machine logged on and
unattended.

2a. the network policy must have no timeouts that will log off or
lock the workstation after a short period of inactivity, OR

2b. the hacker must get access to the unattended logged-on
machine before the timeout expires.

3. the hacker must know what application is used for storing the
information he wants to hack.

4. the hacker must know how to look at that application and
figure out it's stored in an Access MDB.

5. the hacker must know how to figure out how to located that MDB
file from the information available in the front end MDB.

6. the hacker must know how to bypass any restrictions on the
front end MDB that protect the information about the location of
the back end data file.

7. having located the back end, the hacker must know how to gain
access to the Jet-secured back end.

8. having gained access, the hacker will need to examine the data
structure and figure out how to change the data without being
detected.

9. the hacker must do all of this without being discovered
working at the PC of the absent office worker.

How likely are all of these things?

Possible?

Absolutely.

But if the machines that are authorized are not in locations that
students have access to and have appropriate policies applied,
then the window is very narrow.


I've been meaning to ask Mike whether any of these users systems
also have internet access. Not a big deal, but it would be
terribly interesting if the answer were yes.


An exellent point. Also, email and firewall.

As I've said repeatedly, the main line of defense is a proper
network infrastructure that limits who can access the data store.
Most of the tasks above take little time. It is true though that
doing them all with no initial knowledge of the system is
unlikely. However, who says it would be an all-in-one type deal.
Why wouldn't the attacker just get the fe the first time, and get
no further, then crack it at home, realize what they were looking
for, and come back for the backend?
Well, you're assuming they have ready access. Administrative policy
should make this difficult -- the machines where the data entry is
done should be in areas where students are not normally allowed and
there should be policies that those machines be logged off or
locked when not in use.

While a student could slip in and get access to a logged on
machine, the window of opportunity should be quite small, so the
second chance might never come.
Now, it's possible that a hacker could just ship a copy of the
file of to a different location, then at her leisure, hack the
data structure and figure out how to undetectably alter the back
end, then they'd have to have a moment of opportunity to be back
at an unattended, logged-on workstation to munge the data.


Damn it. You did it again!


Heh. Perhaps you should read to the end before replying!

But that's no fun!
There are a whole lot of ifs here, a whole lot of knowledge
necessary, and a whole lot of opportunities needed.

Yes, it could all come together, but it is not something that
could happen, I believe, without planning and luck *if* the
working environment is appropriately limited, i.e., if the
locations from which the data can be accessed are severely
limited and controlled.

What you do in Access to make things less obvious only add to the
amount of time


and increase the amount of interest


But only for the person presented the opportunity to get that far.
it takes to munge the data once the opportunity to
work at the unattended workstation has presented itself. So, to
me, the first line of defense is actually making sure that
unattended logged-on workstations are the exception, and that the
likely hackers are not given access to those machines, unattended
or not. And password policies have to be very strong and the
network infrastructure designed to be as narrowly available as
possible.


Sure.


And you're right about Internet access and the vulnerability to
Trojans. Of course, it's kind of hard to plan for that -- a student
would have to email a trojan to somebody, who would then have to
infect his machine with it (and not be caught by AV software or
blocked by the firewall) and then the student could have access via
the Trojan.

But that's assuming an awful lot, too.
But I still think the things you *can* do with Access itself are
worth doing, as people do leave their workstations unattended,
and unauthorized people can sit down at those unattended
workstations. Putting up a few more barriers in Access simply
increases the amount of time needed to break the system, and I
think that's worth it, if one assumes that someone gets through
all the policies and procedures and mechanisms put in place to
reduce that chance that someone gets that far in the first place.


Fair enough, but I think that Access security, like any weak
security system, wastes developers time and creates undue hazards
because people first come to it with the assumption that it must
be basically workable, even though they know that all systems are
eventually crackable. . . .


If by "people" you are excluding Mike MacSween and me, I'd
basically agree with you. I really don't think that Mike and I are
in the dark here about what's going on, though.
. . . The more weak security features you add to
a system, the more likely (not less) that system is to be
compromised in the long-term - that's my view. You may not agree
with me, but I think the more time you spend thinking about these
sorts of things, the more likely you are to see my point, and even
possibly agree with me.


I don't see how adding a few ultimately crackable barriers in back
end compromises other unrelated security measures. It's only if one
omits the other measures in the hope that the crackable barriers
will be good enough that it is a problem.

And that's clearly not the case in the present example, don't you
agree?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #85
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
I'm only saying that the population that is a danger is limited to
the people who know these things. That is some percentage less than
100% of computer users. I am certain that is is far less than 50%
of computer users.
A lot less than that. It's a music department, with a thriving music
technology section. The head of that section knows far better than I the
business of digitisation of analogue audio, and knows the leading music
software apps very well. Pro Tools and Logic backwards (though I'm the
Finale guru, sad isn't it?). And those sorts of people are very used to
getting to know software and finding their way round machines, setting up
partitions and seperate physical drives for audio files and such. But the
words 'subnet mask' produced a look of incomprehension. A comment from me
of, 'actually Fred, if you hold down the control key then you can select
multiple non-adjacent cells in the Excel sheet, so you can make them all
pink at the same time'. Time after time, teaching Finale or Cubase, a
student's machine crashes (fancy that, midi apps crashing on Windows!) and
they are presented with some IPF message box or other with nothing but an OK
button on it. Do they click it? No, they ask me for help. They don't have
any other options, but they still don't know what to do. I ask clerical
officers when they've 'lost' a file, where is it? Is it on a network drive
or the local disk? The what? OK the picture in windows explorer, did it have
what looks like a pipe along the bottom? What was it, an excel spreadsheet?
Word file? Users don't know how to display file suffixes. They don't know
how to display files in lists so we can see the date stamp (instead of that
bloody stupid icon layout with the ridiculous windows logo that takes up
half the frigging screen). A while ago, before I learned how to create a
desktop shortcut for other users, I could only figure out how to create a
desktop shortcut if I was logged on as that user. And she wasn't there. So I
put the db front end in a folder I'd remember went home. Called next day. It
took me an hour, a whole hour, to talk her through creating a shortcut, when
the file's already there. How long would that take one of us? 15 seconds?
most of which is waiting for explorer to open. How long have you been
working on that new corporate strategy Word document Ethel? Oh about 5
hours. And it's still called document 1? Don't you think it's about time you
saved it? And so on.

I have never be surpised by the high level of skill of most computer users.
I wait with eagerness to find a user who will have even the faintest idea of
how to start getting through some of the stuff we've discussed.
Yes, if they get the opportunity to sit down at a logged-on PC in
the office of someone authorized to use the application, they could
then use their knowledge to get the information.
Which they'd be lucky to get.
Yes, I assume proper administrative and network policies in these
administrative offices, and that the PCs that have access to the
database application are not in places readily accessible to
students.
I personally install the FE. And right now I'm doing the next stage. Which
is tying it to the machine in such a way that I think means it can't be
moved. OK that just stops people taking it away and attempting to break the
FE. But it's more obfuscation. They'll simply GIVE UP at some point. Though
the real reason for that is so that I know where the database is accessible.
I see you over-estimating capabilities of the general user
population and assuming wide-open access. And it seems to me you're
not accounting for the purpose of this application, storing student
grades, when evaluating the risk. Students are the risky
population, as authorized employees have no motivation for hacking
the data, and students shouldn't have access to the database in the
first place. Also, Mike has mentioned that there are paper records
from which the the data entry is done, so there's always an audit
trail. A student would be unlikely to be able to alter the paper
trail as well as munging the data. It's also unlikely that even an
authorized employee would be able to completely alter the audit
trail.

Think of how this works:

1. teacher grades papers.
Yup
2. teacher records grades in gradebook.
Well, individual comments forms. NCR triplicate.
3. teacher records grades on grade sheet for turning in to the
administrative workers for data entry.
Yup, NCR triplicate
4. teacher makes photocopy of grade sheet for files.
One to admin, one to file, one for teacher.
5. data entry person enters grades and files grade sheet turned in
by student.
Yup.
6. data entry person prints out data entry summary and files that
with original grade sheet.


Eventually.
Not at all. I think that the better techniques are worth
pursuing, as long as one is quite clear about their faults, and
the weaker ones are, yes, not only a complete waste of time but
also simply add to the creator and users sense of perceived
security while providing no additional benefit (in other words,
they actual decrease security by reducing concerns in an
unjustified manner).


I disagree vehemently.


Me too. How often does it happen? New thread methinks

Yours, Mike MacSween
Nov 12 '05 #86
"David W. Fenton" <dX********@bway.net.invalid> wrote...
Why do you assume that Mike and I are not smart enough to make that
kind of judgment?


Because he us not keeping it to himself? Proudly proclaiming is methods and
asking people to find flaws in them points to a very different agenda from
him.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

Nov 12 '05 #87
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
"David W. Fenton" <dX********@bway.net.invalid> wrote...
Why do you assume that Mike and I are not smart enough to make that
kind of judgment?
Because he us not keeping it to himself? Proudly proclaiming is methods

and asking people to find flaws in them points to a very different agenda from
him.


And what is that agenda Michael? Do tell, I'd love to know. You seem to be
gifted with telepathy.

And what makes you think that I have any sort of 'agenda'? What's that, a
list of things to discuss at meetings? What makes you think that I'm doing
anything apart from investigating ways of making Access more secure. If you
can't read newsgroup postings exactly the way they appear, at least from me,
then I'm afraid your paranoia has got the better of you.
Nov 12 '05 #88
"Mike MacSween" <mi******************@btinternet.com> wrote in message news:<3f***********************@news.aaisp.net.uk> ...
That's an interesting link Joan. Apart from the usual sexist implication
('look, even lady secretaries can find Access cracking tools')


Hehe - no-one specified they were ladies... ;-)
Nov 12 '05 #89
"Andrew Reddaway" <ba******@hotmail.com> wrote in message
news:c0**************************@posting.google.c om...
"Mike MacSween" <mi******************@btinternet.com> wrote in message news:<3f***********************@news.aaisp.net.uk> ...
That's an interesting link Joan. Apart from the usual sexist implication
('look, even lady secretaries can find Access cracking tools')


Hehe - no-one specified they were ladies... ;-)


No? Read the link:

'These ladies were not trained hackers'

Sometimes you PI people just go to far.

Mike MacSween
Nov 12 '05 #90
Your posts about your methods were clearly aimed differently than your later
posts claiming you understand the limits.

I have no idea what your agenda is, but clearly you are looking at
obfuscation as a way to get better security. There is as reason that both
the crypto and the security/admin communities look unfavorably on that
approach, and it is a shame that you do not recognize the flaw in trying to
obtain better security that way.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
"David W. Fenton" <dX********@bway.net.invalid> wrote...
Why do you assume that Mike and I are not smart enough to make that
kind of judgment?
Because he us not keeping it to himself? Proudly proclaiming is methods

and
asking people to find flaws in them points to a very different agenda from him.


And what is that agenda Michael? Do tell, I'd love to know. You seem to be
gifted with telepathy.

And what makes you think that I have any sort of 'agenda'? What's that, a
list of things to discuss at meetings? What makes you think that I'm doing
anything apart from investigating ways of making Access more secure. If

you can't read newsgroup postings exactly the way they appear, at least from me, then I'm afraid your paranoia has got the better of you.

Nov 12 '05 #91
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
Your posts about your methods were clearly aimed differently than your later posts claiming you understand the limits.
Not sure what you mean by that, but if that I've changed my
approach/attitude/mind over the course of this thread, then yes, I have.
Clearly the thread was started, by me, as a way of finding out more. I try
not to come here with fixed opinions.
I have no idea what your agenda is,
Then what the hell does 'Proudly proclaiming is methods and
asking people to find flaws in them points to a very different agenda from
him.' mean?

If you've got something to say say it. But spare me the hints that you know
what my 'agenda' is.
but clearly you are looking at
obfuscation as a way to get better security.
Yes, I think that making things less obvious increases security. You don't.
Difference of opinion, semantics and perspective. No more to say.
There is as reason that both
the crypto and the security/admin communities look unfavorably on that
approach,
Good for them.
and it is a shame that you do not recognize the flaw in trying to
obtain better security that way.


Something having a flaw doesn't mean it does have worth. A flaw is just
that. A crack in a diamond. Access is flawed.

Yours, Mike MacSween
Nov 12 '05 #92

On Sun, 16 Nov 2003 09:54:39 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
I really don't think that's easy or intuitive. To get past steps 1-6 and
then the rest. It needs a lot of determination, knowledge and intelligence
and the desire to actually do the thing (and the willingness to be caught
doing it and risk getting 0 for everything).


Perhaps, instead of assuming your potential attackers to be hopelessly
inept at the intended task, or simply accepting what I say which is
that such an assumption is dangerous and inappropriate, you could set
up a little sample test, asking four students to try and change their
grades on a system which is similar to, but not precisely the same, as
the one you intend to implement. Of course, you'd be letting them
know that such a system exists (which you felt, in prior posts, was
part of your 'security' and not at all intuitive to them), but given
that starting point, perhaps the results might be revealing and
helpful to the design of the system.

Of course, the reward you offer them for success would have to be
substantial enough to have them actually tell you honestly whether
they were successful in their attempts. There have been cases where
successful attacks are reported as unsuccessful because the reward for
keeping success hidden outweighs that gained by reporting it to the
contest organizers.

Just a thought.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #93
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:9l********************************@4ax.com...
Perhaps, instead of assuming your potential attackers to be hopelessly
inept at the intended task, or simply accepting what I say which is
that such an assumption is dangerous and inappropriate, you could set
up a little sample test, asking four students to try and change their
grades on a system which is similar to, but not precisely the same, as
the one you intend to implement. Of course, you'd be letting them
know that such a system exists (which you felt, in prior posts, was
part of your 'security' and not at all intuitive to them), but given
that starting point, perhaps the results might be revealing and
helpful to the design of the system.


Yes, I've considered that. And rejected it for precisely the reason you
state. At the moment the students aren't aware specifically that such a
database exists. Or if they are what form it's in, machines it's on etc.

I may well do it at paying clients, where they are perfectly clear that they
have a system developed by me using Access 2000, with data held on the
server etc. etc. But I don't know if it does much for my reputation. If I've
described the security as being like such and such and then asked them to
break into it what message does that give them? If they fail it looks like I
thought it was OK, it turned out to be OK, but I wasn't sure. If they
succeed it looks inadequate.

A better test would simply be amongst friends. And I can rate those pretty
much from hopeless beginners (computing-wise) to 'power users', to
developers, database programmers and at the 'top' at least one who is
responsible for the security management of a database system that uses
Microsoft technologies.

Yours, Mike MacSween
Nov 12 '05 #94

On Sun, 16 Nov 2003 20:52:34 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
So, you're saying that the student name is stored in the grade
record? Or that the student follows the foreign keys to the
students table?
The latter. I'd assume Mike's got his normalization skills down pat.
And how long does it take him to identify a good student?


Oh, please. Um. Billy wants a better score. He's in a class
with Tommy Braniac and Sam Slowpoke. He says to himself, 'boy,
I'd like great grades like Tommy Braniac. But who's score should
I copy. Damn, I wish I was smart enough to work out which
student's score in my class I should clone if I want to get a
score like Tommy Braniac's'. God, this is tricky stuff.


It would be if the information you assume is blazingly obvious is
not stored in a format that is human readable.

First off, even with no encoding of names or foreign keys, a grade
is going to be at least 3 tables away from the student name:

tblGrades ->
tblAssignments ->
tblClasses ->
tblClassesStudents ->
tblStudents


It's be attacked in reverse order to this, but that's of little
consequence.
The student doing the hacking is going to have to understand
database structure and be able to read and interpret the schema.
Yes. It's not really all that difficult. Even with scrambled key
values (enforced from the fe - remember Mike was, in his latest post,
still assuming ri was enforceable, if not enforced), they are easy to
map across tables. In fact, the student hardly cares whether he is
student 16 or student -164826485.
You're assuming a linear encryption.


That's what was proposed. . . .


That's what was given as an initial example, with the advice at the
end that you'd probably want to do something beyond that.


And then as I point out each addition weakness, the reply always comes
back, 'well, we have another bandaid for that!'.... I pointed out in
my initial criticism of the suggested encryption approach that it was
possible to address this concern. My point was not that that in and
of itself was a critical stumbling block, but that each of these steps
is a half-assed approach that continues to ignore the true problem.
. . . But actually, I'm not expecting any
such thing. I *was* assuming that each student's id was not used
during key composition for a one-way hash or encryption algorithm,
but as I pointed out, one could compensate for the copying problem
after all.


But you're assuming a couple of things:

1. the student doing the hacking is smart enough to understand a
database schema and figure out which grade records to copy. This
includes not just tracing back to the student, but also to the
appropriate classes and assignments.


A terribly difficult task that would be woefully difficult for anyone
to accomplish, let alone a motivated individual with computer skills
and something to gain.
2. the student names are unencoded plain text.
Not at all. Encrypt the student names and there's still plenty of
other data to readily reveal the true nature of the data. Or was Mike
going to encrypt every text field and every numeric field, because I
hadn't seen the post where he had indicated that he was doing that.
3. the foreign keys are not stored in an encoded format.
Please, David, I KNOW you are smarter than that. Foreign keys, by
their definition, are values in one table that correspond to values,
with additional columns, in another table. Encrypted or decrypted,
such values can be correlated easily.

If you intend to forgo referential integrity and relationships, and
use different encryption keys for the same values in different tables,
then always decrypt in your own code before comparing data, then you
are no longer talking about foreign keys at all. You could implement
such a system, but it is not the system Mike has been discussing, and
should be performed at the engine level - not from the fe or all
efficiencies of an rdbms are lost.
4. the student has sufficient time given the opportunity for
hacking to figure out all of these things.
A student with time on his hands - go figure.
Encryption is a form of obfuscation, just one that is accepted as
OK because strong encryption systems are so hard to crack.
See my other post on this. The two are not confused with each other
by knowledgable folk. I'll say it again - obfuscation involves hiding
something while (proper) encryption involves removing a piece of
information from the system such that the true information in the
encrypted output can not be extracted without obtaining the removed
piece. In a simple analogy (oh, god, not another one!) obfuscation
would be hiding a key to a house under the mat, or in a flower put, or
in an even trickier location, while encryption would entail locking
the single existing physical key in a vault at the bank, or destroying
the key entirely. Each of these scenarios is relatively easily
compromised (getting a replacement key from the manufacturer if the
real key can not be found, stolen or no longer exists), but
obfuscation is in general mocked because the thief CAN easily obtain
the ORIGINAL key, if they simply look in the right place, while
encryption involves true protection for the existing key, potentially
even destroying it to protect it.

Encryption is not 'accepted as OK because strong encryption systems
are so hard to crack'. Not at all. Encryption is accepted because
there is something fundamentally different about it than about
obfuscation, and that is the removal and protection of certain
information necessary for the extraction of the original message/data.
A weak encryption method may well be weaker than a strong obfuscation
technique. Both would be derided by a security professional, but the
latter is more problematic because its weakness may not be immediately
apparent or discussable in clear terms, whereas a weak encryption
scheme can easily be detected and addressed.
Well, putting packages under the seat in your automobile and
locking the door is a form of security by obfuscation. \
Good example.
Anyone who
gets into the automobile may very well be smart enough to search
under the seats and find your iPod or whatever expensive item
you've hidden. But the point is by hiding it you tempt fewer people
to break in in the first place.
That depends on the neighborhood. In some areas, a car may be more
attractive as a target simply because no personal items of any value
are visible.
. . . It does not refer to the reality that any system that
employs encryption probably is doing so to protect (ie, keep
secret, or hide) something. True encryption works because it is
not necessary to store or transmit elements of the system that can
make it vulnerable, while security by obscurity refers to systems
that leave all, or at least many of the critical security aspects
in the open, hidden only by a hopeful lack of knowledge about
where or how to find or interpret them. Most of the things
suggested in this thread fall into the later category (renaming
files, putting them in different places, using simple encryption
algorithms that are stored in the distributed app, etc).


???

Exactly where in an MDE is the algorithm stored?


Presumably, you mean for the code? Its not.
Or are you
proposing someone decompile the MDE to reverse engineer the
algorithm?
Neither. MDE's can be attacked by other means.
Secondly, you're assuming that these things are true:
<snip>

Here we go again....

David, you are spending way more time trying to justify the strength
of such a system than the attacker would in breaking it. We're just
not going to see eye to eye on this, I'm afraid. I don't really know
whether there is any point in continuing this dialogue.
Well, I don't believe it's really possible to protect data from
authorized users -- you have to trust them, since they can always
input erroneous or invented data through authorized methods that
would be just as damaging as data changed by a hacker. This is the
case even with a secured server-based back end.
Tell the NSA and CIA that sensitive data can not be protected from
authorized users. Of course it can. But its not done by an
incredible series of obfuscation layers. Its done by using strong
encryption, controlled systems, and solid auditing.
And Mike has said that in the case of the app he's working on,
there's a paper trail that documents how the data got entered, so
the paper trail would also have to be altered in order for the
authorized user to get away with it.
Not at all. Does Mike's employer do annual paper to electronic system
audits for pre-existing data (and not just newly entered data)? You
are confusing the possibility that a crack could be detected with its
actual detection. Surely the difference is obvious.
It's like with the electronic voting systems. You've got to have
some non-electronic method of verifying that the electronic data is
correct. That's how you protect yourself from the authorized users.


Oh, please, let's not go there. The reliability of electronic voting
systems is being brought up? So, for instance, voting systems that
were jet-based, with no obfuscation, improper (basic) security in
place, ability to mass update data (ie, no controlled fe), no
electronic audit trails, where paper backups were destroyed before
auditing, and where the owner of the company pushing the software was
a very major contributor to one party - that would be a nightmare
scenario - not a reality, right?
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #95
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com>
wrote in message news:3f********@news.microsoft.com...
"David W. Fenton" <dX********@bway.net.invalid> wrote...
> Why do you assume that Mike and I are not smart enough to make
> that kind of judgment?


Because he us not keeping it to himself? Proudly proclaiming is
methods

and
asking people to find flaws in them points to a very different
agenda from him.


And what is that agenda Michael? Do tell, I'd love to know. You
seem to be gifted with telepathy.

And what makes you think that I have any sort of 'agenda'? What's
that, a list of things to discuss at meetings? What makes you
think that I'm doing anything apart from investigating ways of
making Access more secure.


Actually, I think that wording is part of the problem. You're not
doing anything of the sort. What you are doing is adding some
additional barriers to your application to slow down people trying
to hack it. That's not really "making Access more secure." It's
simply adding some safeguards to your particular application.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #96
pm*****@pksolutions.com (Peter Miller) wrote in
<9l********************************@4ax.com>:

On Sun, 16 Nov 2003 09:54:39 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
I really don't think that's easy or intuitive. To get past steps
1-6 and then the rest. It needs a lot of determination, knowledge
and intelligence and the desire to actually do the thing (and the
willingness to be caught doing it and risk getting 0 for
everything).
Perhaps, instead of assuming your potential attackers to be
hopelessly inept at the intended task, . . .


He's doing nothing of the sort. He's assessing that the likely
users, and thus the population of people who even know there's
something to be potentially attacked, have certain skill levels.
He's implementing features that will prevent certain percentages of
those people from doing things he wants to prevent. 100% success is
not necessary, because he's not looking for bulletproof protection,
just some protection.

Why do you fail to recognize the value of keeping even 50% of the
people from hacking the database?
. . . or simply accepting what I
say which is that such an assumption is dangerous and
inappropriate, you could set up a little sample test, asking four
students to try and change their grades on a system which is
similar to, but not precisely the same, as the one you intend to
implement. Of course, you'd be letting them know that such a
system exists (which you felt, in prior posts, was part of your
'security' and not at all intuitive to them), but given that
starting point, perhaps the results might be revealing and helpful
to the design of the system.
First off, students are the likely hackers, and students don't have
any access to the application that would allow them to hack it.

Second, if they got that access, it would be on a basis that would
be very time-constrained, and each of the small things Mike has
proposed implementing would slow them down.

Because of that, I think some of them are worth doing (though I
certainly wouldn't waste time myself on any kind of encoding of
back end data).
Of course, the reward you offer them for success would have to be
substantial enough to have them actually tell you honestly whether
they were successful in their attempts. There have been cases
where successful attacks are reported as unsuccessful because the
reward for keeping success hidden outweighs that gained by
reporting it to the contest organizers.


What are you on about?

Seems to me you are simply ignoring the realities of the
application Mike is working with.

Yes, he's not getting security.

But the things he's doing might very well prevent someone from
getting into his database.

That's worth something, it seems to me.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #97

David,

On Sun, 16 Nov 2003 21:35:28 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
pm*****@pksolutions.com (Peter Miller) wrote in
<k3********************************@4ax.com>:
On Sat, 15 Nov 2003 22:49:07 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
But with Access alone and no outside expertise, you can't break
the security.
Actually, you can.


By "outside expertise"


No.
I meant knowledge that is not included in
the Access application package itself.
So did I.
In other words, you can't figure out how to beak Access security
with the Access help file.
With the Access help file and a look at any default mdw, and the
system tables in any database. Yes, you can.
So, I guess it's not "outside expertise" for the person who has the
expertise already.
Or a brain. Expertise is something one can gain. Hey, I know a good
example of a group of people whose sole purpose is to gain knowledge
and expertise. What are they called again? Oh, that's right -
STUDENTS!
But a person who doesn't know Access and doesn't know VBA and
doesn't know encryption technologies, they'd have find the
information somewhere outside.

Which is what I meant by my statement.
No. Your implication was clear. Outside expertise involves something
they could not do on their own if they were locked in a room and had
only a non-internet connected pc with Access installed and no phone or
other means of connection to outside expertise. I specifically reject
that. Everything you need to understand and crack Access security is
contained in Access, and does not require outside knowledge or
expertise. Such outside assistance could help, but it is not at all
necessary, nor is a crypto background.
2. that there exists something called "Access security".


And perhaps, since they're using Access, it might be, um, like,
maybe ACCESS SECURITY???


You're assuming a lot that most end users are not going to figure
out.


Oh, yeah, I'm assuming a WHOLE lot.
3. that this security is crackable.


And, despite all the non-crackable security implementations out
there, perhaps, just perhaps this one, unlike all the others,
might be crackable?


You're assuming that have knowledge of the facts and history of
security systems and attacks on them.


No. I'm assuming they've heard a news report sometime in the last
five years. Come on. Ask your average Joe on the street if computer
systems are crackable, if they think their banks, governments,
employers whatever computers are fully secured/securable. They'll get
the answer right every time.
4. that the cracks for this security are readily available.


And if I dod a quick google search, I might find....


If you know what to look for -- see steps 1-3.


I thought I'd already pointed out how stupid it would be to think that
1-3 were reliable barriers to 4.
Then they'd need the expertise to use those cracks.


...some freaking expertise!


Tell me what expertise is needed -- I really have no idea.


Obviously.
A hack that involves writing VBA code will stop the vast majority
of your potential hackers right there -- most people don't know how
to write code.
I think that statement, perhaps more than anything else you've said in
this terribly long-winded thread, perfectly sums up the difference
between our viewpoints. Now, instead of all these assumption lists
you keep posting as some kind of mantra, you (or Mike) turn them
around and provide them to your clients as a list of your security
model principles (we will rely on file names, we will rely on a lack
of intuition on the part of our potential attackers, we will rely on
them not knowing how to use a search engine, we will rely on the fact
that differences between paper trails and electronic versions of the
data could be compared (even if they never are), we will rely on the
lack of ability to read the simplest modern coding language in
existence, etc, etc), perhaps you'd start to see my point.
Wow. What sort of utility do you think these punks would sell? I
mean, OBVIOUSLY its point-and-click stuff, no? . . .


Is it? I really don't know.
. . . What other
complications could have been added? I can't imagine any.


Peter, I don't know whether it's point and click products or
whether it's a recipe for writing VBA code.

Even with point and click, I know plenty of people who are stymied
by a SAVE AS dialog box -- I kid you not.


OK, add that to the list of guiding principles you provide to your
clients about your view of security (we're also rely on the extra
protection afforded by the ability of some/many/whatever people to
correctly navigate a save-as dialog).

<a great deal snipped>
And it only matters in the first place if the database application
and not the instructor is calculating the final grade, which is
never the case in any academic institution I've ever seen.


Because you seem to think that the students primary goal is to change
a particular assignment or test score, and not the final score. I
wonder why you would think this. The student would obviously not care
what composite scores are recorded, but rather what final score is
provided. That is, to me, the obvious target.

But there's no reason to pursue this further. You are comfortable
with employing weak methods in your security toolbox, and I am not.
We disagree about the threats faced and the difficulty involved with
thwarting them. We disagree about the interpretation clients will
make of our statements about security (they rely on our judgements, in
security discussions with them, being technically correct about the
inability to secure applications without instilling a justified
concern is I strongly believe, doing them a disservice).

We're simply not going to agree with each other, and we've both made
our points. I'm quite happy to work with Mike offline as he pursues
development of his security model, but I see no point in continuing
this thread.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
Nov 12 '05 #98
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:9l********************************@4ax.com.. .
Perhaps, instead of assuming your potential attackers to be
hopelessly inept at the intended task, or simply accepting what
I say which is that such an assumption is dangerous and
inappropriate, you could set up a little sample test, asking
four students to try and change their grades on a system which
is similar to, but not precisely the same, as the one you intend
to implement. Of course, you'd be letting them know that such a
system exists (which you felt, in prior posts, was part of your
'security' and not at all intuitive to them), but given that
starting point, perhaps the results might be revealing and
helpful to the design of the system.
Yes, I've considered that. And rejected it for precisely the
reason you state. At the moment the students aren't aware
specifically that such a database exists. Or if they are what form
it's in, machines it's on etc.

I may well do it at paying clients, where they are perfectly clear
that they have a system developed by me using Access 2000, with
data held on the server etc. etc. But I don't know if it does much
for my reputation. If I've described the security as being like
such and such and then asked them to break into it what message
does that give them? If they fail it looks like I thought it was
OK, it turned out to be OK, but I wasn't sure. If they succeed it
looks inadequate.


Er, you've just proved Peter's point. If you don't know the answer
already, you really shouldn't be saying you do.
A better test would simply be amongst friends. And I can rate
those pretty much from hopeless beginners (computing-wise) to
'power users', to developers, database programmers and at the
'top' at least one who is responsible for the security management
of a database system that uses Microsoft technologies.


I don't think it's relevant to know if somebody could hack your
application. Of course there's always someone out there who could
do it. The only relevant questions are:

1. how likely is it that someone with the necessary skills could
find themselves in circumstances that would allow them to use those
skills to compromise the database?

2. how likely is it that this person would have motivation to do
so?

3. would the damage be detectable and correctable?

4. would the damage really matter, in the end?

5. what would it cost to prevent this entirely?

It doesn't really matter if there is even one person or 1,000,000
people in the world who could hack your application. What matters
is how likely you think it is that someone *would* do so, and how
much it would matter if they did.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #99
pm*****@pksolutions.com (Peter Miller) wrote in
<h0********************************@4ax.com>:
David, you are spending way more time trying to justify the
strength of such a system than the attacker would in breaking it.
We're just not going to see eye to eye on this, I'm afraid. I
don't really know whether there is any point in continuing this
dialogue.


I agree. You refuse to acknowledge the facts that I've posted
repeatedly. You insist on assuming a highly skilled attacker with
unrestricted access to the database and unlimited time to work with
it.

I have repeatedly shown that:

a. the people with access won't have either the skills or the
motivation to attack.

b. the people without access but who have the motivation will have
extremely limited time.

And I have never said once that there was no possibility that
knowledge, motivation and opportunity would not come together, just
that by implementing the little tricks that Mike has proposed you
putting up small barriers that increase the time it takes to access
and understand the data. Given that opportunity is very limited,
that added time could be crucial.

I see no point in going further.

You just don't see the situation as I do, and won't be changing
your mind.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: craig | last post by:
I am working on my first .NET development project that involves custom role-based security per the project requirements. This lead to a general design issue this week that really caused us some...
32
by: Mike MacSween | last post by:
Further to 'Security - more complex than I thought' Has anybody ever seen any studies? Or anecdotal evidence? Done any studies themselves? Done any lab testing - you know - 10 users asked to get...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.