Security - more complex than I thought

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

Re: Security - more complex than I thought

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" <mike.macsween. nospam@btintern et.com> wrote in message
news:3fb86ec9$0 $52881$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> "Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
> message news:3fb85133$1 @news.microsoft .com...[color=green]
> > "David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote...
> >[color=darkred]
> > > 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=green]
> > asking people to find flaws in them points to a very different agenda[/color][/color]
from[color=blue][color=green]
> > 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[/color]
you[color=blue]
> can't read newsgroup postings exactly the way they appear, at least from[/color]
me,[color=blue]
> then I'm afraid your paranoia has got the better of you.
>
>[/color]

[Mike MacSween]

Re: Security - more complex than I thought

"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
message news:3fb8d769$1 @news.microsoft .com...[color=blue]
> Your posts about your methods were clearly aimed differently than your[/color]
later[color=blue]
> posts claiming you understand the limits.[/color]

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.
[color=blue]
> I have no idea what your agenda is,[/color]

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.
[color=blue]
> but clearly you are looking at
> obfuscation as a way to get better security.[/color]

Yes, I think that making things less obvious increases security. You don't.
Difference of opinion, semantics and perspective. No more to say.
[color=blue]
> There is as reason that both
> the crypto and the security/admin communities look unfavorably on that
> approach,[/color]

Good for them.
[color=blue]
> and it is a shame that you do not recognize the flaw in trying to
> obtain better security that way.[/color]

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

[Peter Miller]

Re: Security - more complex than I thought


On Sun, 16 Nov 2003 09:54:39 -0000, "Mike MacSween"
<mike.macsween. nospam@btintern et.com> wrote in
comp.databases. ms-access:
[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]

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

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:9lthrvov2s me2atljc2mgma38 33sbtoba7@4ax.c om...
[color=blue]
> 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.[/color]

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

[Peter Miller]

Re: Security - more complex than I thought


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

The latter. I'd assume Mike's got his normalization skills down pat.
[color=blue][color=green][color=darkred]
>>>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[/color]

It's be attacked in reverse order to this, but that's of little
consequence.
[color=blue]
>The student doing the hacking is going to have to understand
>database structure and be able to read and interpret the schema.[/color]

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

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

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.
[color=blue]
>2. the student names are unencoded plain text.[/color]

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.
[color=blue]
>3. the foreign keys are not stored in an encoded format.[/color]

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.
[color=blue]
>4. the student has sufficient time given the opportunity for
>hacking to figure out all of these things.[/color]

A student with time on his hands - go figure.
[color=blue]
>Encryption is a form of obfuscation, just one that is accepted as
>OK because strong encryption systems are so hard to crack.[/color]

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.
[color=blue]
>Well, putting packages under the seat in your automobile and
>locking the door is a form of security by obfuscation. \[/color]

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

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

Presumably, you mean for the code? Its not.
[color=blue]
>Or are you
>proposing someone decompile the MDE to reverse engineer the
>algorithm?[/color]

Neither. MDE's can be attacked by other means.
[color=blue]
>Secondly, you're assuming that these things are true:[/color]

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

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

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

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

[David W. Fenton]

Re: Security - more complex than I thought

mike.macsween.n ospam@btinterne t.com (Mike MacSween) wrote in
<3fb86ec9$0$528 81$5a6aecb4@new s.aaisp.net.uk> :
[color=blue]
>"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com>
>wrote in message news:3fb85133$1 @news.microsoft .com...[color=green]
>> "David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote...
>>[color=darkred]
>> > 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=green]
>> 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.[/color]

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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<9lthrvov2sme2a tljc2mgma3833sb toba7@4ax.com>:
[color=blue]
>
>On Sun, 16 Nov 2003 09:54:39 -0000, "Mike MacSween"
><mike.macsween .nospam@btinter net.com> wrote in
>comp.databases .ms-access:
>[color=green]
>>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]
>
>Perhaps, instead of assuming your potential attackers to be
>hopelessly inept at the intended task, . . .[/color]

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?
[color=blue]
> . . . or simply accepting what I
>say which is that such an assumption is dangerous and
>inappropriat e, 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.[/color]

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

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

[Peter Miller]

Re: Security - more complex than I thought


David,

On Sun, 16 Nov 2003 21:35:28 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue]
>pmiller@pksolu tions.com (Peter Miller) wrote in
><k34ervs1lnqrt q66urr33f616vbj 806top@4ax.com> :
>[color=green]
>>On Sat, 15 Nov 2003 22:49:07 GMT, dXXXfenton@bway .net.invalid
>>(David W. Fenton) wrote in comp.databases. ms-access:
>>[color=darkred]
>>>But with Access alone and no outside expertise, you can't break
>>>the security.[/color]
>>
>>Actually, you can.[/color]
>
>By "outside expertise"[/color]

No.
[color=blue]
>I meant knowledge that is not included in
>the Access application package itself.[/color]

So did I.
[color=blue]
>In other words, you can't figure out how to beak Access security
>with the Access help file.[/color]

With the Access help file and a look at any default mdw, and the
system tables in any database. Yes, you can.
[color=blue]
>So, I guess it's not "outside expertise" for the person who has the
>expertise already.[/color]

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

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

Oh, yeah, I'm assuming a WHOLE lot.
[color=blue][color=green][color=darkred]
>>>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]

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

I thought I'd already pointed out how stupid it would be to think that
1-3 were reliable barriers to 4.
[color=blue][color=green][color=darkred]
>>>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]

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

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.
[color=blue][color=green]
>>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=green]
>> . . . What other
>>complicatio ns 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]

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

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

[David W. Fenton]

Re: Security - more complex than I thought

mike.macsween.n ospam@btinterne t.com (Mike MacSween) wrote in
<3fb8fbd5$0$528 85$5a6aecb4@new s.aaisp.net.uk> :
[color=blue]
>"Peter Miller" <pmiller@pksolu tions.com> wrote in message
>news:9lthrvov2 sme2atljc2mgma3 833sbtoba7@4ax. com...
>[color=green]
>> 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.[/color]
>
>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.[/color]

Er, you've just proved Peter's point. If you don't know the answer
already, you really shouldn't be saying you do.
[color=blue]
>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.[/color]

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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<h0uhrv0koa344j sqtqd2n0rhomgmn 42qnu@4ax.com>:
[color=blue]
>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.[/color]

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

[James Neumann]

Re: Security - more complex than I thought

Inline:

dXXXfenton@bway .net.invalid (David W. Fenton) wrote in message news:<9434B1EA5 dfentonbwayneti nvali@24.168.12 8.78>...[color=blue]
> mike.macsween.n ospam@btinterne t.com (Mike MacSween) wrote in
> <3fb5dd60$0$528 88$5a6aecb4@new s.aaisp.net.uk> :
>[color=green]
> >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.[/color]
>
> 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.[/color]

Hear! Hear!

We have quite frequent conversations with clients (potential and
actual) regarding security, and the first thing I ask is if they have
done background checks on their employees. Amazing how many who ask
extremely detailed questions on application security haven't looked
into the backgrounds of their staff. A number don't even have
physically secure server rooms, or regular password rotation policies,
or regular cleaup of login accounts. Yes, I know these are basic, but
a lot of shops just don't do them...

And in almost all workplaces, there is an enormous amount of data
stored "outside" applications in email, spreadsheets, etc. Once you
are on the network, these are wide open.

Security HAS to be multi-layered, and dynamic. Having said that, I
wouldn't use Access/Jet for app that had to keep data secure. But, and
this is a big but, building an app that is secure to a high level will
add significantly to the cost.

[Peter Miller]

Re: Security - more complex than I thought


David,

On Sun, 16 Nov 2003 21:51:13 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue][color=green]
>> . . . 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?[/color]

I've already said elsewhere that I don't wish to continue this thread.
This is the last of the unread posts I see at this time, and perhaps a
good place to close because it sums up a key difference between us.

I meant what I said above, and was not forgetting that obfuscation
methods were added to a system that already maintained standard Access
and o/s level protection mechanisms.

I believe weak methods (especially obfuscation techniques) in general
weaken security even in such cases, for two primary reasons. They
tend to make the system creators/adminsitrators/managers feel security
has been 'enhanced' when it has not, and therefore remove a prime
catalyst for proper security review/analysis which is a proper
understanding of the threats faced/addressed. Also, they provide a
candy-trail for attackers. Every time an attacker sees and solves one
of your weak methods, they (a) realize how screwed up your sense of
security is if you decided to employ such a method was part of your
security posture and (b) are one step further 'into', and therefore
engaged with cracking your system. Think about it this way. If you
use strong encryption, one of the first hurdle an attacker faces is a
serious hurdle which is well publicized, and for which there are
no/few solutions (probably limited to brute force attacks or hacks
knows to the signal intelligence orgs onle). But with the sort of
systems you and Mike are talking about, each hurdle is easily
compromised, with no real difficulty. Every time the attacker solves
such a simply puzzle, they are presented with another layer that is
also addressable (perhaps with a little more effort). You are telling
the attacker that they are indeed up to the task, and that you have
not employed very difficult barriers to them reaching their goal.

For a simple example of this sort of enticement, just look at the
gaming industry. Games that are many leveled and involves challenges
starting from very simple ones and building to quite involved ones are
terribly popular, and gamers build skills (albeit useless ones) and
understanding as they work through the layers. A game that has just a
couple of levels and results in virtually everyone losing, every time,
and right off the bat, is not going to have many fans.

Security is not like gaming, sure, but I do think that implementing
weak security measures is ALWAYS a bad idea, and comes back to haunt
you in more ways than one.

With that said, I'm out of 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

[Mike MacSween]

Re: Security - more complex than I thought

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
[color=blue]
> Er, you've just proved Peter's point. If you don't know the answer
> already, you really shouldn't be saying you do.[/color]

No. Those clients wouldn't think about 'hacking' the application. It's a
small family business. It's their data. Everybody in the organisation has,
or will have soon, at least read permissions to the data. Some have
read/right permissions. They know they can get at the data to run the
business. The idea of breaking into their own database is ridiculous to
them. If I ask them to do it as a security test they may very well have a
go. And if they succeed or not will simply be a measure of their
determination to complete the test I've set them. As we have said ad
nauseum, somebody who wants to can break into an Access database, no matter
how well secured, given enough x, y and z. So if I say that 'the security of
the system is enough to prevent casual tampering with the database by
unauthorised users' (for instance) and when I ask them to test it they get
it then what has it proved? How casual were they. It doesn't 'prove'
anybody's point atall.

You perhaps also try to come up with a form of words to describe the
security of your systems. Do you then invite the users to break in? There is
no number we can use to describe security. We can't say its 70% secure.

Mike MacSween

[Mike MacSween]

Re: Security - more complex than I thought

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
news:94367E346d fentonbwaynetin vali@24.168.128 .74...
[color=blue]
> 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.[/color]

Well yes. That's what I meant. I can't do anything to make the product
Microsoft Access more secure. I can do things to make applications I develop
using Microsoft Access more secure.

Mike

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:c60irvck6g buppgbcc02i7a7n rg2u4kq5n@4ax.c om...
[color=blue]
> 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.[/color]

But you're wrong on this.

This might seem clever Peter and it's not meant to be. But you are a highly
experienced developer and have delved into security deeply. Where will you
find the 'final score' in the back end database? Use your knowledge of
normalisation and data schemas. Now imagine that I do actually go to the
extreme length of using non-obvious or even encrypted table names and field
names. Even encrypted data. What are you now looking for? Imagine you
actually know nothing about database structures. You've managed to crawl
your way through the maze of NT security, Access security (or Access
'security' if you like <g>), Mike's patented highly secret security system,
hidden shares etc. Because you're a student with time on your hands and
you're good at trawling the web for warez sites and stuff. Now you find
yourself at the back end data file which looks like gobbledgook.

YOU might eventually figure out that of course the final score isn't stored
anywhere. I'll bet you most students won't. Unless they're 3rd year
relational database students. It's derived data. Of course. I know we
weren't talking about that, and if you'd taken the time to consider the
actual design YOU would probably have figured that out. They won't. A table
in a back end data file will open as a datasheet, most students will look at
that and think 'spreadsheet', and start looking for a name, and a total,
like you just assumed.

Final score = sum module CATS *(sum(assignmen t*% of module))* year CATS

Actually it's a great deal more complex than that. There are aggregate
queries feeding crosstabs feeding other crosstabs. I forget the details now,
except it was a bloody nightmare. Obviously I did that because it's good
design. But it's another level they've got to get through. And if they
succeed makes their attempts even more detectable. If you want to get _just_
a first you've got to do some pretty clever stuff with a calculator to make
sure you alter only those marks that won't be obvious, but only enough to
just get past the threshold. Of course it's easy if you've got the FE, where
all the queries. are, but...

Yours, Mike MacSween