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