Security - more complex than I thought

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<4amarv0aecnhfl q4qdfp1oeaidbq5 mtrdc@4ax.com>:
[color=blue]
>On Fri, 14 Nov 2003 20:57:28 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote in comp.databases. ms-access:
>[color=green]
>>Seems to me Mike is telling his clients not "pretty good" but
>>"good enough for the circumstances we've foreseen and within the
>>budget we've got and within the estimation of potential risk that
>>we foresee at the present time."[/color]
>
>Really? You really think that the clients will take "good
>enough for the circumstances we've foreseen and within the budget
>we've got and within the estimation of potential risk that we
>foresee at the present time." as being anything less than an
>endorsement of the security capabilities of their application?
>I'd say that such a statement would very much be taken by the
>client as 'don't worry about security in this app - it's up to the
>task'.[/color]

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

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

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

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

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

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

[David W. Fenton]

Re: Security - more complex than I thought

michkap@online. microsoft.com (Michael (michka) Kaplan [MS]) wrote
in <3fb57b1e$1@new s.microsoft.com >:
[color=blue]
>Obscurity is not security, and it is irresponsible and unrealistic
>to assume this is good enough, for anyone.[/color]

I, for one, have said exactly that.

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

None of them do business with credit card numbers.

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

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

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

[David W. Fenton]

Re: Security - more complex than I thought

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

--
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
<suicrvgn1o5h6b vamkrbj2nt23g8j gf0pr@4ax.com>:
[color=blue]
>Wayne,
>
>On Sat, 15 Nov 2003 11:31:46 GMT, Wayne Gillespie
><bestfit@NObes tfitsoftwareSPA M.com.au> wrote in
>comp.databases .ms-access:
>[color=green]
>>I do NOT claim that any of the above provides 100% security or is
>>better or worse than any other method, it is merely another layer
>>of defence[/color]
>
>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?
And how long does it take him to identify a good student?

You're assuming a linear encryption.

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

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

It's possible to make a system complex enough that it's not really
reasonably possible for a human being to be able to figure it out
just by looking at the raw data.
[color=blue]
>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. What Wayne has described is simply the basic idea of
using a complex structure to store the information, a structure
that is not sufficient by itself to be interpretable, i.e., you
have to have the key to convert it to something
human-comprehensible.

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

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

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

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

[David W. Fenton]

Re: Security - more complex than I thought

mike.macsween.n ospam@btinterne t.com (Mike MacSween) wrote in
<3fb567dc$0$528 82$5a6aecb4@new s.aaisp.net.uk> :
[color=blue]
>"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
>[color=green]
>> It's perfectly reasonable to depend on Jet user-level security
>> and NT permissions and logging for a certain level of protection
>> against user exploits, given a certain determination by the
>> organization that the cost/benefit ration is appropriate for the
>> level of risk they are willing to be exposed to.[/color]
>
>Thank you David. A simple enough point. And just the one I'm
>trying to make.[/color]

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

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

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

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

And that's worth something.

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

[David W. Fenton]

Re: Security - more complex than I thought

pmiller@pksolut ions.com (Peter Miller) wrote in
<4cjcrvs49aaulh nv0bp9q3f2mm0pa vvckc@4ax.com>:
[color=blue]
>The way to beat most security systems is not to read up on the
>manuals, study code samples, push new boundaries, expend great
>brain power, blah, blah, blah. Instead, a common and quick route
>to success is simply to think about what the system must be
>doing/allowing in order for an authorized system to work (any
>Access application has to be able to at least read data to display
>it) and then knowing that, do likewise outside of the system.[/color]

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

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

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

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

Now, the vulnerability is not exactly the same.

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

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

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

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

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

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

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

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

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

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

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

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

How likely are all of these things?

Possible?

Absolutely.

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

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

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

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

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

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

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

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:4cjcrvs49a aulhnv0bp9q3f2m m0pavvckc@4ax.c om...[color=blue]
>
> Mike,
>
> On Sat, 15 Nov 2003 07:23:00 -0000, "Mike MacSween"
> <mike.macsween. nospam@btintern et.com> wrote in
> comp.databases. ms-access:
>[color=green]
> >Still, took me a fair time to get there didn't it?[/color]
>
> I don't think you really want to push that line of argument too
> strongly...
>
> Look, here's the deal. You're talking as if all this stuff is rocket
> science. You probably think that the openness you just discovered is
> obscure and not at all obvious to a clueless user, but I disagree.
>
> Here's why.
>
> The way to beat most security systems is not to read up on the
> manuals, study code samples, push new boundaries, expend great brain
> power, blah, blah, blah. Instead, a common and quick route to success
> is simply to think about what the system must be doing/allowing in
> order for an authorized system to work (any Access application has to
> be able to at least read data to display it) and then knowing that, do
> likewise outside of the system. Point being that I never tried the
> method I proposed, nor did I sweat it when you said it didn't work,
> because I knew it *would* work because I knew that you had not,
> through the o/s, prevented the file from being read, because I knew
> you could not do that without Access failing to draw back the data to
> display it. It was trivial. You pointed out permissions that you had
> pulled from the file hierarchy, but I knew there was one permission
> that you had not and could not pull or your app wouldn't work. I
> won't get more specific so you don't fret about your student's google
> searches - BUT AT LEAST YOU ARE NOW CONSIDERING IT POSSIBLE THAT
> POTENTIAL MALEVOLENT USERS OF YOUR SYSTEM WILL KNOW HOW TO SEARCH THE
> NEWSGROUPS/INTERNET - something Michka and I told you a lot earlier
> was something that you had to take into consideration even for your
> most clueless users[/color]

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

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

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

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

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

Probably not much more to discuss.

Thank you very much for you input.

Yours, Mike MacSween

[Mike MacSween]

Re: Security - more complex than I thought

Some good ideas there, thanks Wayne.

Yours, Mike

"Wayne Gillespie" <bestfit@NObest fitsoftwareSPAM .com.au> wrote in message
news:l0sbrvc2bf fp08m8plo0980qn qeaga08b5@4ax.c om...[color=blue]
> On Sat, 15 Nov 2003 06:00:05 -0000, "Mike MacSween"[/color]
<mike.macsween. nospam@btintern et.com> wrote:[color=blue]
>[color=green]
> >"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
> >message news:3fb57b1e$1 @news.microsoft .com...[color=darkred]
> >> Obscurity is not security, and it is irresponsible and unrealistic to[/color]
> >assume[color=darkred]
> >> this is good enough, for anyone.[/color]
> >[/color]
> <snip>
>[color=green]
> >
> >In this particular case:
> >
> >1. Only those people who know about the database even know it exists.[/color][/color]
They[color=blue][color=green]
> >may or may not tell their friends/relatives and so on.
> >
> >2. At the moment the people who know about the database already have some
> >access to it.
> >
> >3. They would need a desire to change the data without authority.
> >
> >4. Theft of the data would not bring down the organisation. It may
> >constitute a breach of the data protection act, especially if it were[/color][/color]
widely[color=blue][color=green]
> >published.
> >
> >5. Unauthorised alteration of the existing data is more of a concern.[/color][/color]
It's a[color=blue][color=green]
> >database for recording student marks. Students are the ones who might[/color][/color]
want[color=blue][color=green]
> >to alter marks. They have to get past NT security first. It's on a domain
> >they don't have access to, in the ordinary course of events. Of course,
> >people leave machines on etc. etc. We know that NT security can be
> >circumvented in various ways, often 'socially'. That is beyond my[/color][/color]
control.[color=blue][color=green]
> >And of course the same caveat applies to all the college's data.
> >
> >6. The academic process involves the discussion of each student's overall
> >year mark, then degree award, at a board of examiners. Usually 10-20[/color][/color]
members[color=blue][color=green]
> >of the academic staff, most of whom will know the students' work fairly
> >well. Borderline students are always discussed. A student who had
> >significantl y higher grades than was expected would be noticed, I think.[/color][/color]
The[color=blue][color=green]
> >parts of the course which contribute to the class of degree contain only[/color][/color]
7[color=blue][color=green]
> >modules. Some of those modules might only contain 1 or 2 assignments.[/color][/color]
There[color=blue][color=green]
> >is a high probability that the member of staff who marked those[/color][/color]
assignments[color=blue][color=green]
> >will be present and would remember that actually Jo Soap didn't get 80[/color][/color]
for[color=blue][color=green]
> >that piece of work, but 55. And the marks are always recorded in paper[/color][/color]
form[color=blue][color=green]
> >first, and that list of marks is present at exam board. That brief[/color][/color]
outline[color=blue][color=green]
> >of how the system is used is why I don't think that you have enough
> >information to comment on whether Access security (and anything else I[/color][/color]
might[color=blue][color=green]
> >use) is 'good enough' for me. You don't know the context in which the
> >application is used. I do. No doubt there are plenty of 'ah, but what[/color][/color]
ifs'[color=blue][color=green]
> >you have ready for me. I'd be interested to hear them.
> >
> >7. I will present a precis of this thread to the management of the[/color][/color]
college,[color=blue][color=green]
> >incorporatin g a summation of your, Peter's and others' comments. At that
> >point my professional duty is done. The college management can then make[/color][/color]
the[color=blue][color=green]
> >decision whether to abandon computerise record keeping, move to a[/color][/color]
database[color=blue][color=green]
> >server system, or continue with what I'm developing for them.
> >
> >Yours, Mike MacSween
> >
> >[/color]
>
> So we all agree that Access security is severly flawed.
> You have mentioned several methods you can employ to make manipulation of[/color]
the data file more difficult for many users. In the scenario you have[color=blue]
> outlined above I would be inclined to build an interface which would make[/color]
the data meaningless without the front end, and tightly control how the[color=blue]
> scores are entered in the front end. This would, to a large extent make[/color]
the Access security flaws irrelevent.[color=blue]
>
> In your scenario it would appear that in reality the score is the critical[/color]
data piece that must be protected. Therefore I would design an interface[color=blue]
> specifically designed to protect the integrity of the score.
>
> I would create a set of custom encryption / decryption functions eg -
> '============== =============== =============== ======
> Function fEncryptScore(c urScore As Currency, intRevNo As Integer) As[/color]
String[color=blue]
> fEncryptScore = (((curScore * 10000) / 123) + 456)
> fEncryptScore = fEncryptScore & intRevNo
> End Function
> '============== =============== =============== ======
> Function fUnencryptScore (strEncryptedSc ore As String) As Currency
> Dim strCheckScore As String
> strCheckScore = Left(strEncrypt edScore, Len(strEncrypte dScore) - 1)
> fUnencryptScore = ((strCheckScore - 456) * 123) / 10000
> End Function
> '============== =============== =============== ======
> Use whatever calculation you like as long as it is reversable.
>
> ?fEncryptScore( 75,1)
> 6553.5609756097 61
>
> ?fUnencryptScor e(6553.56097560 9761)
> 75
>
> Make sure the FE is an mde so the functions are not {easily} readable.
>
> The score would be entered via an unbound textbox in a form and encrypted[/color]
by your function and stored in it's encrypted form.[color=blue]
> Me.ScoreField = fEncryptScore(M e.ScoreEntry, Me.RevNo)
>
> Once the score has been entered I would never allow the record to be[/color]
edited. If the score needs to be changed I would add a new record and leave
the[color=blue]
> existing record intact. I would include a Revision No, EnteredBy[/color]
(CurrentUser()) , and TimeStamp (Now()) fields in the table containing the
score. Up[color=blue]
> the RevNo by 1 each time a new record is added for the student.
>
> The score would only be displayed in the form in a disabled textbox using[/color]
the function -[color=blue]
> =fUnencryptScor e(Me.ScoreField )
>
> If the datafile is opened directly the score will display a meaningless[/color]
number.[color=blue]
> Without the encryption key, editing this number is a hit and miss affair.
>
> If the record is edited using the frontend you will have a 2nd record[/color]
added for the student. If you have suspisions about the score you could
verify[color=blue]
> with the CurrentUser entered in that record whether they did in fact[/color]
change the score.[color=blue]
>
> If they get real smart and change the score in the frontend and then open[/color]
the table and copy the new score to original record and then delete the 2nd[color=blue]
> record, the last digit of the encrypted score (RevNo) will not match the[/color]
rev no of the original record.[color=blue]
>
> You could then write a loop to search for *suspicious* records (more than[/color]
1 record for student / RevNo does not match encrypted value)[color=blue]
>
> Obviously this is a simplified example and your actual requirements will[/color]
be far more complex than you have outlined, but my point is that the problem[color=blue]
> can be tackled from more than one direction.
>
> I do NOT claim that any of the above provides 100% security or is better[/color]
or worse than any other method, it is merely another layer of defence that[color=blue]
> can be employed which has no dependancy on Access Security (apart from[/color]
getting the CurrentUser).[color=blue]
> I certainly would NOT recommend this method (or similar) for cc or other[/color]
highly sensitive data and in your case, as Peter and David have stated[color=blue]
> previously you MUST fully discuss whatever method(s) you choose with the[/color]
people responsible for the database and allow them the final decision.[color=blue]
>
> Personally I wouldn't use Access for any secure purpose unless[/color]
(ImportanceOfDa ta <= (EffortToCrack /2))[color=blue]
> But there are many, many purposes that meet this criteria.
>
>
> Wayne Gillespie
> Gosford NSW Australia[/color]

[Mike MacSween]

Re: Security - more complex than I thought

Thanks very much for you input everybody, especially Peter, Michael and
David.

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

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

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

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

Thanks folks, Mike MacSween

[TC]

Re: Security - more complex than I thought


"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:suicrvgn1o 5h6bvamkrbj2nt2 3g8jgf0pr@4ax.c om...[color=blue]
>
> Wayne,
>
> On Sat, 15 Nov 2003 11:31:46 GMT, Wayne Gillespie
> <bestfit@NObest fitsoftwareSPAM .com.au> wrote in
> comp.databases. ms-access:
>[color=green]
> >I do NOT claim that any of the above provides 100% security or is better[/color][/color]
or worse than any other method, it is merely another layer of defence[color=blue]
>
> One that is completely bypassed by the student opening the backend and
> copying the encrypted score from Tommy Braniac's student record to his
> own, without ever worrying about the encryption.
>
> Yes, yes, you can compensate for that too, but the point is that
> adding more and more simple obfuscation layers[/color]

Why do you say that's "obfuscatio n"? Effective crypto has always required
not only making the information "undecipherable ", but also, protecting it
against being changed. There are various well-known techniques for detecting
when data has been changed (eg. MACs). The use of those techniques is not
"security by obscurity".

TC

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

[David W. Fenton]

Re: Security - more complex than I thought

dXXXfenton@bway .net.invalid (David W. Fenton) wrote in
<9434BEDB2dfent onbwaynetinvali @24.168.128.78> :
[color=blue]
>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]

Oh, dear. My typist has a dirty mind.

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

[Peter Miller]

Re: Security - more complex than I thought


On Sat, 15 Nov 2003 23:25:11 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue][color=green]
>>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=blue]
>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=blue]
>You're assuming a linear encryption.[/color]

That's what was proposed. But actually, I'm not expecting any such
thing. I *was* assuming that each student's id was not used during
key composition for a one-way hash or encryption algorithm, but as I
pointed out, one could compensate for the copying problem after all.
[color=blue]
>You're also assuming the encrypted data can be understood
>sufficiently to be interepreted by a human being well enough to
>allow them to copy data.[/color]

Phht. I'm basing my comments on the suggestions made. It REALLY
DOESN"T TAKE MUCH INTUITION TO CRACK SUCH A SYSTEM.
[color=blue]
>Say, for instance that a grade was recorded in *two* tables,[/color]

or three, or four, or maybe five.

Obfuscation is obfuscation - period.
[color=blue]
>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=blue][color=green]
>>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. 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=blue]
>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.

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=blue]
>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=blue]
>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=blue]
>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. I know you mentioned it
above, but it should be stressed that you can never, with Access,
prevent access to the raw data file, whereas with a true server rdbms,
you can indeed protect the raw file (again, this doesn;t mean that o/s
vulnerabilities don't exist there too, but it does mean that the raw
data file doesn't need to be exposed for the rdbms to use it, as it in
fact must be for Access).


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Peter Miller]

Re: Security - more complex than I thought


On Sun, 16 Nov 2003 11:27:05 +1200, "TC" <a@b.c.d> wrote in
comp.databases. ms-access:
[color=blue]
>Why do you say that's "obfuscatio n"?[/color]

Please be clearer. I was referring to using a simply translation
algorithm which wasn't keyed off anything student-specific. That is
obfuscation alone.
[color=blue]
>Effective crypto has always required
>not only making the information "undecipherable ", but also, protecting it
>against being changed. There are various well-known techniques for detecting
>when data has been changed (eg. MACs). The use of those techniques is not
>"security by obscurity".[/color]

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

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Peter Miller]

Re: Security - more complex than I thought


David,

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

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

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Peter Miller]

Re: Security - more complex than I thought




On Sat, 15 Nov 2003 22:49:07 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote in comp.databases. ms-access:
[color=blue]
>pmiller@pksolu tions.com (Peter Miller) wrote in
><t0oarvcqscbr0 fhrec08dk8tjhv6 crdath@4ax.com> :
>[color=green]
>>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=blue]
>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=blue]
>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=blue]
>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=blue]
>4. that the cracks for this security are readily available.[/color]

And if I dod a quick google search, I might find....
[color=blue]
>Then they'd need the expertise to use those cracks.[/color]

....some freaking expertise!

[color=blue]
>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=blue]
>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? What other
complications could have been added? I can't imagine any.
[color=blue]
>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=blue]
>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=blue]
>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=blue]
>3. how to navigate to the back end.[/color]

The front-end details that.
[color=blue]
>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=blue]
>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=blue]
>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).


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