Protecting your password isn't the real problem here. It sounds like you want
an architecture that works for both your ASP and Power Builder implementations.
For your ASP solution, you're using the COM object on the server (correct
approach). For your Power Builder solution, you're using the COM object on
the client (wrong approach).

Scalable solutions generally don't create database connections on the client.
One approach would be to move the COM object to the server in your Power
Builder approach. The PB app can still use the COM object, but just remotely.
If you're concerned about firewalls, proxy servers etc., use RDS instead
of DCOM to reference the remote object:

Dim ds As RDS.DataSpace
Dim obj as Object
Set obj = ds.CreateObject("https://app.mydomain.com", _
"MyProject.MyClass")

Very easy. Check out MSDN to find out how to use RDS.

This approach requires the COM object to be stateless (no properties, global
variables, etc.). It also assumes that the COM object isn't going to be heavily
queried by the PB app - that it will be used to provide just data access.
If your COM object is heavily used by the PB app (meaning lots of wire traffic
to the server), you should partition the object into data access and other
services.

By placing the COM object that creates the database connection on the server,
you benefit from database connection pooling (a major scalability factor).
If you use RDS, you also make the application robust for the Internet (using
HTTP or HTTPS over port 80 for all client/server traffic).

With regard to protecting the password, I'd recommend giving the application
server (running IIS and MTS) a public and a private IP (dual-homed). The
database server should have just a private IP. That way, all traffic between
the application server and the database server happens on your private network,
not on the Internet. This does more than protect your passwords - it protects
your entire database server from easy hacking.

You can use a DSN with username/passwords or integrated security (NT domain
authentication). It's hard to implement user-level auditing (unless you have
Win2K), so most people set a single user account for opening the database
connections (e.g., use the MTS package identity).

To implement user-level auditing in the database, most people maintain usernames/passwords
in a file or database on a secure (private IP) server. The COM object checks
its context to get its username. It then looks up the password for the username
from the username/password file or database. Using the username and password,
it connects to the database server using a connect string. You must maintain
accounts for each user within the database server (an admin hassle).

Tom Shreve

"Jason D" <jason@quodata.com> wrote:
>
>I have a COM object. This object is used on a ASP page and it is also use
>on a Client Machine through PowerBuilder. The object needs to connect to
>the database. So in the ASP page and the PB app i load into the registry
>the database i'm connecting, userid and password. And the COM object reads
>the info from there. The only thing i have done in both environments for
>security is i encrypt the username and the password. So when the COM object
>uses them they get decrypted first and then it connects. Does anyone have
>a
>better way of doing this?
>
>