#170 Table-level and field-level passwords

[Anonymous]

Exported from Bugzilla, issue 3909.

--- Comment added on 9/23/02 12:10:40 PM ---
David Miller, 9/16/2002

My situation is like Germaine's in my applications. I supply FFE only for
rarely needed alterations to files. The way things are going, though, it
looks like I'm going to just have to supply my own maintenance routines
instead of using FFE. I really need Table level passwords, and I am tiring
of fixing FFE with every new update in order to make it usable in my
situation. Looks like I need to just keep FFE as my own personal tool, and
make some maintenance procedures in my applications. :-) No big deal, but
if FFE was tweaked a little bit, it would have made a nice maintenance
utility in its own right that could be distributed with applications and
used for maintenance or repair situations.

If there were an interest in making FFE more versatile, following are the
things needed:

1) ability to limit FFE to SUP in a property setting

2) some method for FFE to recognize password fields and automatically hide
them (maybe by all strings with the first characters being "@@@@" or
something similar, or maybe if FF invented / created a field type of
password.

3) FF needs to handle table level passwords to restrict those few system
files that the developer uses and doesn't want anyone getting into.
Alternatively, have some kind of flag on certain files that prevent FFE from
browsing them... again, settable by a property setting so that the developer
can have his own version that can get in, or perhaps prompt for a password
upon trying to open tables marked as such. Maybe this could be something
like using the hidden files attribute on such files, or by setting the
file's attribute flag as a system file.
==================================================
David Miller, 9/18/2002
What you don't seem to understand is that many end users don't even know how
to copy files. It might be easy for someone like you to circumvent Paradox
style Table passwords, but not most of my end users. I suspect a simple
scheme like this that would take maybe one day to implement in the standard
code of Flash Filer would greatly help some of us who write applications for
dummy end users. I suspect the primary problem is having to change the
header structure to accommodate a password, so maybe it should be something
to consider for Flash Filer 3.0.

Consider the idea of having FFE prompt for some canned password before
allowing browsing a file with a system file attribute set on it. Sure, that
is easy for virtually millions of developers to circumvent, but that might
be all that is needed to block most of my users who call me to help them
copy a file somewhere and don't have a clue as to what a file attribute is.
They would get stopped at the password prompt and know that they shouldn't
be messing around in that particular file. We are not talking about people
intent on cracking the system, just users snooping around where they should
not be snooping. Heck, a lot of them would probably stay out of the file if
they just had a message say, "this file is a system file, we don't recommend
you open it. Are you sure you want to open this file?" LOL.

Seems at least that FFE might be able to be set not to show hidden files,
just like windows explorer hides hidden files unless a setting is changed to
make it show hidden files. That would probably be good enough for some of
us, and easy enough to implement.
==================================================
David Miller, 9/20/2002
> From my point of view, having no security is better
> then having security that is easy to circumvent. That
> point is driven home for us with the flak we get for
> the encryption we use to secure communications
> between a client a server.

I understand and agree with you that there will always be people to complain
about it not being good enough. However, I would not agree with you that
simple security measures are worse than no security measures at all. For
example, you offer the ability for a developer to provide his own encryption
routines, but for my needs, the file encryption that you guys provide is
great. I don't have hackers trying to break in. I just occasionally have a
few snoopy users, and then there are other users who just feel better
knowing that their information is "encrypted."

Ben wrote:
> Stop-gap measures are fine in certain instances, but
> when we advertise a secure, reliable database we
> can't implement these types of security enhancements.

With regard to table level security, I don't see what the problem is with
admitting its weaknesses. There are small padlocks that are easily broken
off with a hammer and then there are huge safes that standard explosives
can't crack. Developers understand these concepts. It seems like you are
avoiding any kind of table level security measures because you fear the
criticism. Paradox had all kinds of criticism for how easy it was to break
their table passwords, but that didn't stop a lot of developers from using
table passwords anyway. They worked great for me, even though anybody with
a little knowledge could snatch a program off the internet to crack the
passwords. I actually liked the idea that they were easy to crack because
that meant if a password to an old table was forgotten it would be easy to
retrieve.

Ben wrote:
> ... if you want to keep people from using a demo
> version of FFE to access your data then use
> different ports for your server and client
> applications.

I am not at all concerned about any users getting a demo version and using
it. Again, the level of users I am talking about don't even know how to
copy a file. I am talking about very simple measures that would allow me to
distribute FFE with my application and maybe even link a shortcut to it when
the system is installed. Right now I distribute FFE with it, but I don't
feel comfortable providing a menu link to it. If I could just set the
hidden file attribute on my files that I don't want FFE to show, that would
be a huge help for my security purposes. Some of my users will never ever
see FFE even though it is in the application directory. Once in awhile,
something happens that makes me need to get in there and modify a few fields
in the system. FFE comes in real handy for this, but it is a little too
open for me to provide it freely to end users as a tool. What I'm doing is
distributing it with my application, but not advertising it as being there.
If it had a few of these enhancements that stayed with the product in future
updates, then I could advertise it more and probably cut down a little on
support calls as more savy users could use FFE to fix some of their
problems.

Ben wrote:
> If you need to distribute FFE for certain tasks, then you have
> the source code. It would not be difficult to have FFE filter
> out specific tables, or easier keep users from doing things
> with specific tables.

That's exactly what I do right now. I modified FFE to ask for a password
upon startup. It accepts several different passwords so that depending on
which password is entered, FFE will either not load, load but restrict
access to certain files, or allow full access to all files. That way I can
keep certain files within the reach of some people, and certain files only
within my reach. The problem is that whenever an update is released, I have
to take a few hours to apply my modifications to the new FFE version. I
skipped updating to 2.10 because I simply did not have time to do all these
changes. I'm about to update to 2.11 (still haven't gotten around to it),
and so that is why this is on my mind and I am expressing my desire that
some of these things were resolved in the base source code of FFE.

What I anticipate happening is that my modifications may become such that I
simply quit updating to newer versions of FlashFiler. The problem with that
is that after many years, my software becomes kind of obsolete. I still
have an application that uses BTree Filer because of these kinds of issues.
I don't want to keep going down that road, so that is why I am expressing my
concerns.