From: David W. Fenton on
Salad <salad(a)oilandvinegar.com> wrote in
news:wZCdndbzAZlVQe3WnZ2dnUVZ_u6dnZ2d(a)earthlink.com:

> The way I look at is...I don't care much for the data. My concern
> is my code and the manipulation of data.

I'm exactly the opposite. The only security I care about is for the
data. I don't care if anybody breaks into my code. They will be
amazed at the beauty and cleverness of it and who would want to deny
them that?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on
Banana <Banana(a)Republic.com> wrote in
news:4B715B18.60500(a)Republic.com:

> In the same thread, however, I've pointed out that accde seems to
> be of limited use in context of web database because macros are
> still editable. I've yet to find a way to use Sharepoint's
> security upon those macros. I can deny the access to downloading
> the file and offer only rich client database for download, which
> is why I tend to agree with David that there's really not much new
> security to Access.
>
> Data, OTOH, isn't even protected at all by mde/accde. It still can
> be linked, queried, and modified. A necessary condition, I suppose
> if one were to have legitimate need but there's just no way to
> prevent illegimiate use short of moving the data out from Access
> files into a server-based RDBMS (or Sharepoint as well) and thus
> using their security mechanisms to manage the permissions to data
> at object or even at row/column level.

As I said, there is NO SECURITY in Access 2010 -- the claim of
"enhanced security" is rubbish. You can't enhance what isn't there.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on
David W. Fenton wrote:
> There is no way to use a database password to build a secure Access
> application. The db password is not security at all.

Just so you know - you're preaching to the choir here.

But out of interest - what would you consider to be a properly secured
file? If it's not encryption + password then what else can one do to the
file so that it couldn't be used by unauthorized people?

The real security comes in not having access to the data in first place,
but that's where Access is basically screwed- it's a _file_-based
database. The access is implied in its design.

At least they made encryption + database password a single unit of
operation in 2007 whereas in 2003 & earlier, you could specify a
database password but the file would still be plaintext. Seriously lame.
I'm still not clear whether 2007 uses the password as key and thus
doesn't store the key on the file as was the case with encryption in
2003 & earlier. I'm led to believe that password is used as a key but
would like something definite. Either way, both are/would a step in
right direction, I'd think. But this won't change that all it mean is it
takes more time to reach the data.

(In case anyone doubts that one can crack 4096-bit RSA encryption in a
timely manner- consider this: http://xkcd.com/538/ )


Anyway, I'm not sure what else you can do to secure a file to the point
that unauthorized people can't access the file short of depending on
external resources such as filesystem, OS, or daemon.
From: David W. Fenton on
Banana <Banana(a)Republic.com> wrote in
news:4B71E8A3.8040106(a)Republic.com:

> David W. Fenton wrote:
>> There is no way to use a database password to build a secure
>> Access application. The db password is not security at all.
>
> Just so you know - you're preaching to the choir here.
>
> But out of interest - what would you consider to be a properly
> secured file? If it's not encryption + password then what else can
> one do to the file so that it couldn't be used by unauthorized
> people?

Jet ULS provides a proper system for securing the data and providing
access control. MS could have enhanced its encryption (which was its
main vulnerability, i.e., the passwords were inadequately
encrypted).

> The real security comes in not having access to the data in first
> place, but that's where Access is basically screwed- it's a
> _file_-based database. The access is implied in its design.

I agree. And if you need that level of security you use a different
database engine.

But with the db password there is no way to secure your data, as the
password will have to be embedded in your front end (either in the
code or in the table links), and that means it's not really hidden
at all, as anyone browsing the file with a hex editor can find the
password (all constants and literals in VBA code are encoded
literally, even in an MDE). Sure, you can encrypt your front end,
but without a password on *that*, anybody can decrypt it and then
you're back where you started.

In other words, MS has replaced one ineffectual file-based security
system with one that is EVEN LESS SECURE.

> At least they made encryption + database password a single unit of
> operation in 2007 whereas in 2003 & earlier, you could specify a
> database password but the file would still be plaintext. Seriously
> lame.

To me, they are both lame.

> I'm still not clear whether 2007 uses the password as key and thus
> doesn't store the key on the file as was the case with encryption
> in 2003 & earlier. I'm led to believe that password is used as a
> key but would like something definite. Either way, both are/would
> a step in right direction, I'd think. But this won't change that
> all it mean is it takes more time to reach the data.

I've been told that, contrary to my understanding, even with ACE the
encryption key is stored in the header of the file.

> Anyway, I'm not sure what else you can do to secure a file to the
> point that unauthorized people can't access the file short of
> depending on external resources such as filesystem, OS, or daemon.

That's not the goal at all. By that argument, nobody would ever
bother to install locks on the doors of their homes, since that
won't stop the determined burglar. File-based security can never be
as secure as server-based, but that's not something inherent to the
methods of securing the data, but because of the access to the file
that is required in that context. The reason SQL Server is more
secure is because the demon controls access to the data, and access
to the tools that control the demon are limited. Secondly, the MDF
file for the database is not accessible, and the server is in a
locked server room, and so forth.

It's the same set of issues, but because the system has a single
point of access (the demon) it's possible to make it more secure.

But it's still vulnerable if anybody can get administrative control
or if someone can get physical access to the server. It's orders of
magnitude harder because of that, but it's still not completely
invulnerable.

I still think Jet ULS easily could have been improved with the same
better encryption that the database password got in A2007. It would
have still been crackable because the files are available, but it
wouldn't have been nearly as easy as the old ULS.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on
David W. Fenton wrote:
> Jet ULS provides a proper system for securing the data and providing
> access control. MS could have enhanced its encryption (which was its
> main vulnerability, i.e., the passwords were inadequately
> encrypted).

Ah. Your previous reply left me with the impression that even improved
encryption would be useless but now I realize it's primarily the absence
of access control is what make you perceive it as useless. Apologies.

I have to agree that without access control, it's not terribly
interesting, though I do think encrypting in tandem to specifying a
password was a necessary precondition to proper security. The state of
affair was worse in 2003 when you could create password but still have a
plaintext file. That's like buying a shiny new lock but never installing
it on the door. If ULS were to return, I would still expect that the
file be encrypted when ULS was set up or even not require that the user
need have full permissions on the file, thus enabling the option to
manage permissions with filesystem permissions.

> But with the db password there is no way to secure your data, as the
> password will have to be embedded in your front end (either in the
> code or in the table links), and that means it's not really hidden
> at all, as anyone browsing the file with a hex editor can find the
> password (all constants and literals in VBA code are encoded
> literally, even in an MDE). Sure, you can encrypt your front end,
> but without a password on *that*, anybody can decrypt it and then
> you're back where you started.

Just to point out that we face similar problem when we are using linked
tables with server-based RDBMS that doesn't use Windows authentication.
In one project, I solved this by doing this way:

1. Ask my user for a password.
2. Hash it quickly & discard the plaintext.
3. Select a salt.
4. Combine Salt & hash in some manner then re-hash. (I used SHA-256)
5. Send #4 in as the actual password granting them access to the backend.

This way, I never need to save the password in the file, the user supply
the piece but doesn't actually know the real password that was sent to
the server. Salt are, for lack of better term, "deterministically
randomly selected" so while they could read the salts in the MDE, they
wouldn't know which salts was actually used, and even so, they don't
actually know what algorithm I used to combine the salt & hash (which is
also "deterministically randomly" selected as well) and MDE has compiled
up the algorithms so they'll need to pull out a decompiler. Once
authenticated, it was all up to the backend server's security mechanism
to grant them the necessary permissions to the data as they work in the
application.

So, yes, the need to send password in is a serious problem but can be
solved with careful application. I can only hope that Microsoft will fix
this significant hole so it won't require considerable setup on the part
of developer, especially one not practiced in field of security. I also
imagine that for where it is not acceptable/desirable for user to enter
in a password, the above wouldn't be acceptable, though it still can be
solved by making use of API calls to interrogate the computer, windows
user login, whatever and using this as a password, thus automating the
#1. But that's still work on the developer when it should have been
provided by Microsoft.

The most ugliest but also most important fact about security is this:
It's far easier to fool one into thinking it secured than to actually
secure it.

> I've been told that, contrary to my understanding, even with ACE the
> encryption key is stored in the header of the file.

I would expect that it'd store the hash... what else to compare the
entered password with? But if the unhashed key is in fact stored in the
header, then well... That's still lame. Still would like to get a
definite answer on this.