> Option 3)
>
> Return to old method (used by IBO 3). The old method
> fails just when the programmer forgots to remove this
> in the final version.
> This method as a good advantage: if it's ok, don't touch.

Its not "just" a matter of forgetting to remove from the final
version. As someone that occassionally receives demo apps etc, I used
to regularly receive passwords with them. What started my concern
with passwords was scanning my harddrive and discovering passwords
embedded in a about two dozen projects and several executables and
object files in plain text. Its just so easy to set and forget.

If I found that on my system - and I pride myself on being relatively
security conscious - then I dreaded what was happening to those that
were not aware of how this worked. It was this realisation that
started me looking for a better way, and I thought I had found it. Oh
well :-(

Anyone out there still using IBO3 - perhaps you would be interested in
performing a search of your harddrives for files containing your IB
password? I am curious to know just how many people are surprised at
how many places it turns up. Were my original concerns valid, or was
I just being paranoid?

> I really don't like Option 1) because of the registry
> thing...

Option 1 does not have any "registry thing". It may cause some
initial disruption because people already using IBO4 may have
passwords stored via a registry stored encryption key. Option 1 is
similar the same as the old version except that I make some attempt to
obscure the password using a hardcoded key value. Its not much
better than plain text but would prevent your average user from
reading the password directly from the executable. In addition it
provides the PasswordRemembered property which we can default to not
saving the password so that people must deliberately set this property
and so be aware of what they are doing.

> And I really don't like Option 2) because I don't think
> there is the need to complicate something that could be
> simple.

I think that this is a very valid point. I can solve my own security
concerns in my usual way (deriving my own variation of such
components), and possibly that is what I should have done to begin
with.

> Could this option 3) be on the survey?

Option 3 (the same as it was in IBO3) - if the user types in the
password at designtime it will be saved in plain text in the DFM and
any resulting executable and object files. It will remain saved
until/unless they eventually clear the value, and clearing the value
will not automatically from any executables and object files that have
already been generated. No separate property to control whether the
password is saved or not, so it is entirely upto the user to remember
to clear the password and delete any files previously generated.

So yes this can be on the survey.



At the moment I am leaning towards my option 1. Reasonably simple but
at least it does obscure the password from general perusal.

The main advantages for option 2 are that it provides the developer
with some inbuilt management facilities if desired, it will not
disrupt existing IBO4 apps - and as Paul Schmidt pointed out - it
opens up the possibility of expansion in the future. However given
the response to the current mechanism I am inclined to leave such work
for each developer to implement for themselves.


Note: I want to "fix" this problem ASAP. The longer it is left asis,
the more people and projects may be impacted my any changes that I
make.


Geoff Worboys
Telesis Computing