Prev: Interacting with Website
Next: Embedding Firefox instead of Internet Explorer
From: The Frog on 9 Feb 2010 03:30
I am not aware of the security model in A2010, or Sharepoint. I am
aware however of the lack of knowledge most people have about
security, especially encryption and access control. I would simply
like to point out that security is not a product, nor a feature, but
is achieved by correct application of design methodologies.

I would be inclined to believe that any security offered by A2010 or
Sharepoint is probably rubbish - but that is just my opinion. If you
really want to secure your data, and your code, then you need to
implement this in code at design time. It takes a lot of work to do
this in Access at this time, but it is possible to achieve both secure
data storage and access as well as code storage. I would imagine that
only a few people using this forum could do this properly.

Please forgive my words on this if they seem harsh, I certainly dont
mean to offend anyone. Security is a topic that I am passionate about.
That being said I am happy to share what I know if anyone wants it.

What I find interesting in A2010 is the ability to work with web
services natively. This would mean that you could work with Google
Docs / Apps for example, and host a completely online and free
database application (client on local machine, tables on the web). I
read somewhere that Google will also be opening up direct access to
their BigTable database system for Google Apps and developers. I would
imagine that with careful design it would be possible to generate a
'generic' front end application that implememted security the 'right'
way and yet provided completely customisable features for applications
- and keep the data online and safe. Now that would be a framework
worth building and sharing (IMO).

Cheers

The Frog
From: Banana on 9 Feb 2010 08:15
The Frog wrote:
> I am not aware of the security model in A2010, or Sharepoint. I am
> aware however of the lack of knowledge most people have about
> security, especially encryption and access control. I would simply
> like to point out that security is not a product, nor a feature, but
> is achieved by correct application of design methodologies.

Agreed.


> I would be inclined to believe that any security offered by A2010 or
> Sharepoint is probably rubbish - but that is just my opinion.

Access 2010's security has not been changed compared to 2007. Sharepoint
security is far preferable only because we're no longer dealing with
files, which by nature will be problematic to secure. This is no
different from moving data into a server-based RDBMS & configuring its
permissions accordingly.

> If you really want to secure your data, and your code, then you need to
> implement this in code at design time. It takes a lot of work to do
> this in Access at this time, but it is possible to achieve both secure
> data storage and access as well as code storage. I would imagine that
> only a few people using this forum could do this properly.

IMHO, implementing security at code level is not really the right way.
Yes, it can be used to good effect (and indeed I do this), but the
security should be at the lowest level and that's usually the database
engine's level. One thing ULS did right was that it was always "on".
There was no way to bypass or circumvent or turn it off. This is similar
to what many server-based RDBMS does - always run by security mechanisms
for every data access requests. Unfortunately, ULS had many other
problems, the main thing being that we had no daemon to shield users
from touching the data file directly. It was by necessity that we deal
with files so it will always be problematic.

At least in 2007, they combined the encryption & database password and
used the database password as key (meaning it's not stored on the file,
if I've understood it correctly) which was a step in right direction and
could have been used for ULS as well and because 2007 now uses external
APIs, it is possible to change the algorithm used to encrypt the file.

But what I think they really missed the point was this: If the security
was file-level, why even bother with database-share password if it could
have been in a folder with appropriate permissions and thus is much more
secure without the extra overhead of encryption?

> What I find interesting in A2010 is the ability to work with web
> services natively.
>
> ...
>
> I would
> imagine that with careful design it would be possible to generate a
> 'generic' front end application that implememted security the 'right'
> way and yet provided completely customisable features for applications
> - and keep the data online and safe. Now that would be a framework
> worth building and sharing (IMO).

How is that different from the approach we've always had available to us
by using server-based RDBMS? I do think the ability to connect to web
services natively is a good feature but it's still same solution in
terms of security by different name, I would think.
From: James A. Fortune on 9 Feb 2010 10:01
On Feb 9, 8:15 am, Banana <Ban...(a)Republic.com> wrote:
> The Frog wrote:

> > If you really want to secure your data, and your code, then you need to
> > implement this in code at design time. It takes a lot of work to do
> > this in Access at this time, but it is possible to achieve both secure
> > data storage and access as well as code storage. I would imagine that
> > only a few people using this forum could do this properly.
>
> IMHO, implementing security at code level is not really the right way.
> Yes, it can be used to good effect (and indeed I do this), but the
> security should be at the lowest level and that's usually the database
> engine's level.

Both are needed. Although my preference would be to store strongly
encrypted data (using code) over protecting the database engine, it's
usually true that only some of the data in a database is sensitive.
That data can be encrypted as strongly as desired and stored, while
the rest can rely on the relatively meager encryption of the database
engine. The lowest level is the data itself.

James A. Fortune
CDMAPoster(a)FortuneJames.com
From: David W. Fenton on 9 Feb 2010 16:42
Banana <Banana(a)Republic.com> wrote in
news:4B716004.7040205(a)Republic.com:

> At least in 2007, they combined the encryption & database password
> and used the database password as key (meaning it's not stored on
> the file, if I've understood it correctly) which was a step in
> right direction and could have been used for ULS as well and
> because 2007 now uses external APIs, it is possible to change the
> algorithm used to encrypt the file.

The database password is no form of security.

> But what I think they really missed the point was this: If the
> security was file-level, why even bother with database-share
> password if it could have been in a folder with appropriate
> permissions and thus is much more secure without the extra
> overhead of encryption?

Exactly. Password protection without access control is of no use in
building an application, so the database password serves no purpose
except to give the uninitiated a sense of false security. And
headaches in building an app with a password-protected back end.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
 | 
Pages: 1
Prev: Interacting with Website
Next: Embedding Firefox instead of Internet Explorer