Maybe I am misunderstanding but when user types a username and password at some point it will be in the memory of the client machine no matter what programming language you are using.  

Hi, Pierre - 

Why not use the Windows Native Authentication feature that is available in Oracle? Then a user is not required to enter a user ID / password.

https://docs.oracle.com/database/121/NTQRF/authen.htm#NTQRF120

In SQL Server, when you create a DBMS Login, you can elect whether the user will connect via Windows authentication (which uses industry-standard LDAP, or Lightweight Directory Access Protocol) or via SQL Server authentication (a database user ID & password).

I'm not an Oracle person, but I would expect it works in a similar manner. Others here can likely verify... or tell me why it doesn't work ;-)

Regards, John

The simplest method would be to set logpass to empty string right after the CONNECT statement. You could encrypt it into a global variable in case you needed to connect again later.

The issue I see with this question is that the user typing in the password and the hacker are the same person so of course they recognize the password in the memory dump. A real hacker isn't going to recognize that string as a password or have knowledge about the internals of PowerBuilder or your app.

If you have a hacker in your network looking for passwords, installing a key logger would be easier than looking at memory dumps. To avoid a key logger, you'd have to use Windows Authentication or whatever Oracle calls it.

To avoid hackers you need to first make sure your network is secured and all users are well trained in how to avoid the hacker tricks. 

This property is used only while connecting a transaction object (connect <using :transaction_object>) to the database. After that, you can reset (clear it) or even better encrypt it.

Andreas.

You can also look at the following question: SQLCA and memory management (appeon.com)

Hi Pierre;

   FYI:   One method that I do in my STD Framework is to automatically encrypt all Transaction Object datum automatically after a DB Connect; command. The encryption algorithm is changed for each instance of a TO (and instance of a PB App EXE) and thus, pretty much impossible to break, as follows:

   If the App Disconnects from the DBMS and then issues another Connect command, the TO knows how to restore (decrypt) the previous login settings for the retry and then re-encrypts the TO's sensitive values again using a new random encryption key.   Food for thought.  HTH

Regards ... Chris

Hi,

Which Database are you using? Oracle should automatically encrypt login information and sql server should have an option for encryption (if I'm not mistaken).

If I understand well, the 'process hacker tool' can do memory dumps. In that case I think the only way to work around this, is by using either integrated login (Active Directory) or maybe a keypair. I'm not an expert at all in this, so maybe someone else can enlighten us on how to do this.

Regards,

MiguelL

Hi all,

One solution I think about is to encrypt the password as soon as it is catched by the user. This way even the user don't know the real password. This mean that the users will be created with an encrypted password.

Example: The user catch the password "Powerbuilder2022" but the real password in the database is an encrypted "Powerbuilder2022"

Regards.