Banana <Banana (AT) Republic (DOT) com> wrote in
news:4B70D3CC.8030109 (AT) Republic (DOT) com:

There is no way to use a database password to build a secure Access
application. The db password is not security at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:wZCdndbzAZlVQe3WnZ2dnUVZ_u6dnZ2d (AT) earthlink (DOT) com:

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/

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4B716004.7040205 (AT) Republic (DOT) com:

The database password is no form of security.

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/

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4B715B18.60500 (AT) Republic (DOT) com:

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/

David W. Fenton wrote:
Does it really matter? I don't really know if a company is going to put
a mission critical app on the web. If sharepoint is secure and the data
is secure, and I can write an app in Access I would not be concerned.
If data is insecure, then A2010 web apps will fall flat on their face.

crack the code. I've used Michka's code to determine a password but
that's about as far as I'd go.

David W. Fenton wrote:
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.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:8oqdnWxHo5TgR-zWnZ2dnUVZ_uWdnZ2d (AT) earthlink (DOT) com:

Yes, of course it matters.

Microsoft is trumpeting "enhanced security" that isn't security at
all.

They are retiring whatever security Access as a database engine ever
offered and replacing it with nothing that is useful *within Access
itself*.

It's impossible to ever fully secure a file-based database engine,
but they could have enhanced the encryption of Jet ULS in order to
make it a lot harder to crack. But they don't want to support it,
so, like Jet replication, they just drop it.

Er, what? What does that have to do with the question of security,
which exists even in a closed network with no Internet access at
all?

And what does that have to do with Access security?

NOTHING.

That code won't work on the ACE passwords, but crackability is not
the reason it's worthless.

The reason the database password is of no value is because to use it
in a multi-user app, the password has to be embedded in your code or
in the table links. And there's only one password per database, so
there's no possibility of access control.

If it's embedded in your code, then you have to encrypt the front
end, and then you have the same issue that you had with Jet ULS. And
you lose compressibility (i.e., won't zip to smaller size), which
can be a big issue in certain situations (downloads, for instance).
And so far as I know, there's no way to prevent someone from
decrypting such a front end, anyway, so you don't really get
anything (anybody who can open the ACCDE can decrypt it, and thus
get access to the password strings embedded in the code in any
case). At least with et ULS, you had to have the appropriate
workgroup file to do that.

There is really no justification for eliminating file-based security
and access control. Everyone locks their doors, but that doesn't
stop determined burglars. But nobody is saying "why bother locking
your doors?" Enhancing the encryption of Jet ULS would have been the
way to go if Microsoft wanted to provide any level of security for
the ACE.

But they clearly did *not*.

And it's a big deal, even for those not using ACE as data store.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4B71E8A3.8040106 (AT) Republic (DOT) com:

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).

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.

To me, they are both lame.

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

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/

David W. Fenton wrote:
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.

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 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.

David W. Fenton wrote:
OK.

It was weird yesterday. I opened an app at work in A2003 from Explorer
and it prompted me for my password. I then opened the same app from
Explorer in A2007 and there was no password prompt. I will assume if I
had opened it in A2007 from a desktop icon that specified the workgroup
I would have been prompted.

In my case yesterday, yup.

I don't know what a file-based database engine is. In the old days of
FoxPro, where the tables were external, I can understand. A self
contained unit like Access, don't know.

havoc on a system. Because you've been given extended right from other
users. I do believe that somewhere along the line a company is forced
to trust somebody.

to make it secure, one should go to the second method. Perhaps MS is
pushing Sharepoint.