I vote for option #1. In my application I have SavePassword set to
false and I enter it each time. I have set my password to 2
characters so it is easy for me to enter it each time. I know that is
not a good length for a password but it makes it handy for
development.

Just my 2c.

Gerald S. Brown

--- In IBObjects@y..., "Geoff Worboys" <geoff@t...> wrote:
> Hi People,
>
> Jason and I have been discussing (offline) the confusion over
> TIB_Connection password storage and how best to resolve the it. We
> are looking for peoples opinions on this topic.
>
> Originally IBO simply stored the password in the DFM as plain text.
> This had the problem that it was easy to forget that the password
was
> there and end up distributing executables and DFMs with your own
> private password.
>
> I attempted to resolve this in IBO4 by obsuring the password using a
> jumble (primative encryption) mechanism, where the key for
encryption
> was stored in the current users registry. This meant that the
stored
> password could not be read on other machines or by other logons on
the
> same machine unless the key was installed for that user/machine. It
> was intended that anyone really wanting to distribute their password
> would code it directly at runtime.
>
> Apparently this has resulted in much confusion and several
> complaints - so we need to resolve this issue, preferably with
minimal
> impact to existing applications.
>
>
> Option 1. Simple but less secure
>
> We keep pretty much what we have except...
>
> The "SavedPassword" property will hidden (not published) and only
used
> by special streaming code - so that it no longer complicates the
> interface.
>
> When PasswordRemembered=true the password will be saved by special
> streaming that only encrypts with a standard key value - hardcoded
and
> the same for all installations. Allowing the application and DFM to
> be distributed and the password to be read without problems
whereever
> the application is executed.
>
> When PasswordRemembered=false the password is not saved. This means
> that during designtime the password must be reentered every time you
> open the form, at runtime the password must be entered via code or
> using the LoginPrompt.
>
> This will still allow people to accidently distribute their password
> (if they have set PasswordRemembered=true and forgotten about it) in
a
> format that can be read and easily decrypted, but at least it is
> simple and hopefully not confusing. I am almost tempted not to
bother
> obsuring the password at all - since the end result is much the same
> and I would not have to bother with special DFM streaming code.
>
> This will disrupt existing installations of IBO4, since any
previously
> saved passwords will have been encrypted with a user specific key.
> However I dont expect this to be a significant problem, simply type
> the password into TIB_Connection again and you should be OK.
>
>
> Option 2. Maximum Control - New PasswordStorage Property
>
> Introduce a new property called PasswordStorage that will replace
the
> PasswordRemembered property (the PasswordRemembered property would
be
> left in place for a period of time to support the upgrade process).
> PasswordStorage would be an enumerated property containing the
> following values...
>
> psNone - password not stored - default
> At designtime the password would have to be reentered every time the
> form is loaded.
> At runtime the password would have to be provided in code or using
the
> loginprompt.
>
> psUser - password encrypted using user specific key
> This is the same as the current mechanism and would prevent the
saved
> password from being used on other machines or logons unless the
> registry key value is also installed. This is the value that would
be
> set when PasswordRemembered is set to true (until that property is
> removed) in order to maintain compatibility with existing
> installations.
>
> psMachine - password encrypted using machine specific key
> Similar to current except that the encryption key is stored in the
> machine registry, providing support for service applications.
> Security implications apply on WinNT and Win2000 machines. Again
the
> application could not be distributed to other machines without also
> installing the registry key value.
>
> psNotSecure - password encrypted with common key
> When set to this value the password is obscured BUT the key value is
> hardcoded and the same for all installations. So the program can be
> distributed and used by anyone and the password easily discovered.
>
>
> We **could** remove the Password property from TIB_Connection (not
> publish it, only make it public) and designtime access to the
password
> would be restricted to use via the SavedPassword property (which
> normally displays the encrypted value). If desired setting this
> property could automatically set the PasswordStorage property to
> psNotSecure.
>
> Alternatively I could hide the SavedPassword property and stream it
> out specially as proposed for option 1.
>
>
>
> If we could rely on people to read the release notes and online help
> there would be many other possibilities. But it appears that most
of
> us seem to follow the golden rule: "Only if all else fails do we
read
> the instructions" :-) So I have proposed the two options above
that
> should have least impact.
>
>
> Comments, suggestions, thoughts???
>
> Geoff Worboys
> Telesis Computing