Security - more complex than I thought

[Peter Miller]

Re: Security - more complex than I thought


On Sat, 15 Nov 2003 23:02:33 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue]
>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.[/color]

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.
[color=blue]
>You seem to be arguing that the only worthwhile protection is "more
>than sufficient for the circumstances we've foreseen, etc."[/color]

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

[Peter Miller]

Re: Security - more complex than I thought


On Sat, 15 Nov 2003 23:52:47 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue]
>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.[/color]

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.
[color=blue]
>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.[/color]

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.
[color=blue]
>But to steal or alter the MDB file if the network and NT security
>infrastructu re 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.[/color]

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?
[color=blue]
>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.[/color]

Damn it. You did it again!
[color=blue]
>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[/color]

and increase the amount of interest
[color=blue]
>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
>infrastructu re designed to be as narrowly available as possible.[/color]

Sure.
[color=blue]
>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.[/color]

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

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:ub2ervguhr l789bq9sgjci9fg 0ukmfepsj@4ax.c om...
[color=blue]
> Oh, please. Um. Billy wants a better score. He's in a class with
> Tommy Braniac and Sam Slowpoke.[/color]

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

Mike

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:ub2ervguhr l789bq9sgjci9fg 0ukmfepsj@4ax.c om...[color=blue]
> Phht. I'm basing my comments on the suggestions made. It REALLY
> DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.[/color]

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 trelStudentCour se tblModule
tblAssignment trelStudentCour seAssignment 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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<ub2ervguhrl789 bq9sgjci9fg0ukm fepsj@4ax.com>:
[color=blue]
>On Sat, 15 Nov 2003 23:25:11 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote in comp.databases. ms-access:
>[color=green][color=darkred]
>>>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 .[/color]
>>
>>How, exactly, does the student know that he's getting a good
>>score?[/color]
>
>Perhaps it wasn't obvious. He went after Tommy Braniac's grades
>and not Sam Slowpoke's. Get it?[/color]

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?
[color=blue][color=green]
>>And how long does it take him to identify a good student?[/color]
>
>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.[/color]

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 ->
tblClassesStude nts ->
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.
[color=blue][color=green]
>>You're assuming a linear encryption.[/color]
>
>That's what was proposed. . . .[/color]

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.
[color=blue]
> . . . 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.[/color]

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.
[color=blue][color=green]
>>You're also assuming the encrypted data can be understood
>>sufficientl y to be interepreted by a human being well enough to
>>allow them to copy data.[/color]
>
>Phht. I'm basing my comments on the suggestions made. It REALLY
>DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.[/color]

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?
[color=blue][color=green]
>>Say, for instance that a grade was recorded in *two* tables,[/color]
>
>or three, or four, or maybe five.
>
>Obfuscation is obfuscation - period.[/color]

Encryption is a form of obfuscation, just one that is accepted as
OK because strong encryption systems are so hard to crack.
[color=blue][color=green]
>>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.[/color]
>
>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>[/color]

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.
[color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>>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 .[/color]
>
>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. . . .[/color]

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.
[color=blue]
> . . . 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).[/color]

???

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.
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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.
[color=blue]
>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.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>Yes.
>[color=green]
>>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.[/color]
>
>True. But remember that your raw Access data file WILL ALWAYS BE
>AVAILABLE IN FULL to any valid users/systems. . . .[/color]

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.
[color=blue]
> . . . 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).[/color]

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

[David W. Fenton]

Re: Security - more complex than I thought

mike.macsween.n ospam@btinterne t.com (Mike MacSween) wrote in
<3fb749bc$0$528 83$5a6aecb4@new s.aaisp.net.uk> :
[color=blue]
>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).[/color]

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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<k34ervs1lnqrtq 66urr33f616vbj8 06top@4ax.com>:
[color=blue]
>On Sat, 15 Nov 2003 22:49:07 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote in comp.databases. ms-access:
>[color=green]
>>pmiller@pksol utions.com (Peter Miller) wrote in
>><t0oarvcqscbr 0fhrec08dk8tjhv 6crdath@4ax.com >:
>>[color=darkred]
>>>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.[/color]
>>
>>But with Access alone and no outside expertise, you can't break
>>the security.[/color]
>
>Actually, you can.[/color]

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.
[color=blue][color=green]
>>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).[/color]
>
>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?[/color]

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.
[color=blue][color=green]
>>2. that there exists something called "Access security".[/color]
>
>And perhaps, since they're using Access, it might be, um, like,
>maybe ACCESS SECURITY???[/color]

You're assuming a lot that most end users are not going to figure
out.
[color=blue][color=green]
>>3. that this security is crackable.[/color]
>
>And, despite all the non-crackable security implementations out
>there, perhaps, just perhaps this one, unlike all the others,
>might be crackable?[/color]

You're assuming that have knowledge of the facts and history of
security systems and attacks on them.
[color=blue][color=green]
>>4. that the cracks for this security are readily available.[/color]
>
>And if I dod a quick google search, I might find....[/color]

If you know what to look for -- see steps 1-3.
[color=blue][color=green]
>>Then they'd need the expertise to use those cracks.[/color]
>
>...some freaking expertise![/color]

Tell me what expertise is needed -- I really have no idea.
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>Wow. What sort of utility do you think these punks would sell? I
>mean, OBVIOUSLY its point-and-click stuff, no? . . .[/color]

Is it? I really don't know.
[color=blue]
> . . . What other
>complication s could have been added? I can't imagine any.[/color]

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.
[color=blue][color=green]
>>So, you're only worrying about the people of ill will who have a
>>little bit of knowledge.[/color]
>
>And we certainly don't need to worry about anyone like that, now,
>do we?[/color]

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.
[color=blue][color=green]
>>With Mike's additional techniques, this person would also need to
>>know:
>>
>>1. that the data files are not stored in the front end.[/color]
>
>Crack the fe. See that it contains nothing data-wise. Move on to
>the backend. Sounds pretty simple to me.[/color]

You're assuming someone knows about front ends and knows that they
need to crack it.
[color=blue][color=green]
>>2. how to locate the back end data file in a secured front end[/color]
>
>The front-end is cracked. Its connection to the backend is now
>obvious.[/color]

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.
[color=blue][color=green]
>>3. how to navigate to the back end.[/color]
>
>The front-end details that.[/color]

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 conceptualizati on 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.
[color=blue][color=green]
>>Those are trivialities to us, but basic conceptual difficulties
>>that could stop certain kinds of people in their tracks.[/color]
>
>How stupid do you really think people are? Obviously more so than
>I would think.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>No. I just see a lot of confusion on this topic, and a lot of
>under-estimating.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>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).[/color]

I disagree vehemently.

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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<qp4ervc00jbitt e0usnqkr7k0qcrg 8jkb4@4ax.com>:
[color=blue]
>On Sat, 15 Nov 2003 23:02:33 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote in comp.databases. ms-access:
>[color=green]
>>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
>>consideration s of any organization, any application, any
>>database.[/color]
>
>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
>clarificatio n.
>[color=green]
>>You seem to be arguing that the only worthwhile protection is
>>"more than sufficient for the circumstances we've foreseen, etc."[/color]
>
>No, but its not a bad goal. Better to err on the side of better
>protecting your system than you intended.[/color]

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

[Mike MacSween]

Re: Security - more complex than I thought

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message

Complete sense. Very well put David.

Yours, Mike MacSween

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<jv4erv8a8t37m7 k8m3oleq9behjbd 08ud7@4ax.com>:
[color=blue]
>On Sat, 15 Nov 2003 23:52:47 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote in comp.databases. ms-access:
>[color=green]
>>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.[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>Don't you hate it when you type a response inline, then see that
>the poster was headed in that same direction? I do.[/color]

Well, at least you said that I already knew it!
[color=blue]
>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.[/color]

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.
[color=blue][color=green]
>>But to steal or alter the MDB file if the network and NT security
>>infrastructur e 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.[/color]
>
>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.[/color]

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.
[color=blue]
>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?[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>Damn it. You did it again![/color]

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

But that's no fun!
[color=blue][color=green]
>>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[/color]
>
>and increase the amount of interest[/color]

But only for the person presented the opportunity to get that far.
[color=blue][color=green]
>>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.[/color]
>
>Sure.[/color]

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.
[color=blue][color=green]
>>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
>>workstation s. 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.[/color]
>
>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. . . .[/color]

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.
[color=blue]
> . . . 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.[/color]

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

[Mike MacSween]

Re: Security - more complex than I thought

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Which they'd be lucky to get.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Yup
[color=blue]
> 2. teacher records grades in gradebook.[/color]

Well, individual comments forms. NCR triplicate.
[color=blue]
> 3. teacher records grades on grade sheet for turning in to the
> administrative workers for data entry.[/color]

Yup, NCR triplicate
[color=blue]
> 4. teacher makes photocopy of grade sheet for files.[/color]

One to admin, one to file, one for teacher.
[color=blue]
> 5. data entry person enters grades and files grade sheet turned in
> by student.[/color]

Yup.
[color=blue]
> 6. data entry person prints out data entry summary and files that
> with original grade sheet.[/color]

Eventually.
[color=blue][color=green]
> >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).[/color]
>
> I disagree vehemently.[/color]

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

Yours, Mike MacSween

[Michael \(michka\) Kaplan [MS]]

Re: Security - more complex than I thought

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote...
[color=blue]
> Why do you assume that Mike and I are not smart enough to make that
> kind of judgment?[/color]

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.

[Mike MacSween]

Re: Security - more complex than I thought

"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
message news:3fb85133$1 @news.microsoft .com...[color=blue]
> "David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote...
>[color=green]
> > Why do you assume that Mike and I are not smart enough to make that
> > kind of judgment?[/color]
>
> Because he us not keeping it to himself? Proudly proclaiming is methods[/color]
and[color=blue]
> asking people to find flaws in them points to a very different agenda from
> him.[/color]

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.

[Andrew Reddaway]

Re: Security - more complex than I thought

"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message news:<3fb560d2$ 0$52887$5a6aecb 4@news.aaisp.ne t.uk>...
[color=blue]
> That's an interesting link Joan. Apart from the usual sexist implication
> ('look, even lady secretaries can find Access cracking tools')[/color]

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

[Mike MacSween]

Re: Security - more complex than I thought

"Andrew Reddaway" <balachai@hotma il.com> wrote in message
news:c03cb198.0 311170329.70784 e2f@posting.goo gle.com...[color=blue]
> "Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message[/color]
news:<3fb560d2$ 0$52887$5a6aecb 4@news.aaisp.ne t.uk>...[color=blue]
>[color=green]
> > That's an interesting link Joan. Apart from the usual sexist implication
> > ('look, even lady secretaries can find Access cracking tools')[/color]
>
> Hehe - no-one specified they were ladies... ;-)[/color]

No? Read the link:

'These ladies were not trained hackers'

Sometimes you PI people just go to far.

Mike MacSween