Prev: Why couldn't exit the MS ACCESS program
Next: Interacting with Website
From: Salad on 10 Feb 2010 13:31
David W. Fenton wrote:
> Salad <salad(a)oilandvinegar.com> wrote in
> news:8oqdnWxHo5TgR-zWnZ2dnUVZ_uWdnZ2d(a)earthlink.com:
>
>>>>>There is no enhanced securithy in Access 2010. Period.
>>>>
>>>>Isn't Sharepoint secure?
>>>
>>>That's not Access.
>>
>>Does it really matter?
>
> Yes, of course it matters.
>
> Microsoft is trumpeting "enhanced security" that isn't security at
> all.

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.

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

In my case yesterday, yup.

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

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.

>> I don't really know if a company is going to put
>>a mission critical app on the web.
>
> 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?
>
Somewhere you have to draw the line. You, as a developer, could wreck
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.

>>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.
>
> And what does that have to do with Access security?
>
> NOTHING.
>
OK. Still, if you have one method that is insecure and another method
to make it secure, one should go to the second method. Perhaps MS is
pushing Sharepoint.
From: Banana on 10 Feb 2010 13:57
Salad wrote:
> 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.

IINM, FoxPro's database engine is also file-based just as Jet/ACE
(although like Jet/ACE, it can work with external sources as well).
Other examples would be SQLite and SQL Server Compact Edition. What it
means is that there are no daemons involved. You open a file directly
and interact with it, perhap sharing it with others at same time. In
case of server-based RDBMS, the daemon has the exclusive access to the
data files and you communicate with the daemon and if you have the
permission, daemon will provide you the data and perform any updates on
your behalf (again, assuming you have the permission). With file-based
database engine, they're just a library that runs in-process with the
given application and locally on the client machine, managing the data
file directly _as_ you and not as a daemon (e.g. as if you were opening
it in Word and editing it).

> OK. Still, if you have one method that is insecure and another method
> to make it secure, one should go to the second method. Perhaps MS is
> pushing Sharepoint.

If they were wanting to replace traditional client/server application
with Sharepoint... I would think that would be a bad decision and a lot
of people will be mightily inconvenienced.

Web or no web, security is needed in all contexts, and this is not the
case here.
From: David W. Fenton on 11 Feb 2010 15:42
Salad <salad(a)oilandvinegar.com> wrote in
news:iLydnYkQbPgRZu_WnZ2dnUVZ_gOdnZ2d(a)earthlink.com:

> Perhaps MS is
> pushing Sharepoint.

Ya think?

Geez, I would have thought that was completely obvious with A2007
already:

1. eliminate replication from ACCDB format -> MS solution: use
Sharepoint for synchronizing data

2. eliminate ULS in ACCDB format -> use SQL Server or Sharepoint

3. add new data types, multi-value fields, attachment fields ->
makes things compatible with Sharepoint

Notice a pattern there?

Then look at all the new things in A2010, even the ones that are
present in plain old Access without any Sharepoint involved, and
nearly everything new is motivated by integration with Sharepoint.
In A2010, at least, some of those new features (like the great data
macros) are really useful for apps that don't use Sharepoint. Most
of the rest of them, not so much.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 11 Feb 2010 15:45
Banana <Banana(a)Republic.com> wrote in
news:4B72F917.3080603(a)Republic.com:

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

I think it would be relatively trivial to decompile an MDE that
isn't encrypted (and password-protected) to figure out what your
encryption code actually does.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 11 Feb 2010 16:34
David W. Fenton wrote:
> I think it would be relatively trivial to decompile an MDE that
> isn't encrypted (and password-protected) to figure out what your
> encryption code actually does.

My understanding is to the contrary. It was mentioned to me by a
non-Access programmer that it would be more difficult to decompile a MDE
compared to an executable (whether compiled to machine code or to
intermediate bytecode). There's plenty of decompilers out there for
C-family languages & Java & .NET languages and even for Visual Basic.
However, good luck finding a MDE decompiler to download & run with few
clicks. Heck, none of those beforementioned decompiler are click'n'run.

Here's a thread where Wayne Phillips, the guy who runs
EverythingAccess.com and offer MDE to MDB conversion service agrees with
this assertion:

http://www.utteraccess.com/forums/showflat.php?Cat=&Board=81&Number=1877894

Of course, if one is so worried about the possibility of someone
decompiling, they could get Wayne's utility to strip out the symbols as
well, but we should do very well to remember that the skill required to
successfully decompile a program (whether it's an executable or a MDE
file) would be very high and most likely out of reach for vast majority
of users, even those who are otherwise fluent developers.

Also, if we're at the point of being sufficiently concerned about
someone decompiling the program in order to extract the algorithm for
salting & hashing, then we're most likely way past the point of Access
being the right tool for the job, IMHO.

I'd actually be more concerned about malware running in the background
logging the keystrokes or tracking the memory heap at this point as it's
far more trivial to write a malware to log the keystrokes or dump the
heap than it is to decompile any program. But that's not my job anymore
- that's IT's job to properly secure the computer and prevent malware
from being present and thus compromising all otherwise well-secured
applications, including mine.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Why couldn't exit the MS ACCESS program
Next: Interacting with Website