On 8 Aug 2001, at 16:38, Geoff Worboys 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.
>

I vote for option 2, mostly because in the future we can add new
PasswordStorage options, without breaking the existing code.

Paul

Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com