Hi Geoff,

I'm new to IBO as you know. Also, I think this "survey" is not
getting the interest of a lot of people - by now it's just
you,Jason,me, Lester and someone that I don't remember the name.

I'm working on just one project with IBO, so really I will adapt to
any situation. I will join my vote to the majority.

I think you can stop this survey now with option 2, that was the more
voted option. Option 1) it's not a good solution for people who
develops in multiple machines: that's the way it's now, and should be
updated because of the complains: I think this survey was online
because of this new option.

I'm with you when you say that this must be done quickly.

Artur Anjos

--- In IBObjects@y..., "Geoff Worboys" <geoff@t...> wrote:
> > 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