1. Pierre DETE
  2. PowerBuilder
  3. Wednesday, 27 April 2022 09:49 AM UTC

Hello,

A customer reports that he was able to retrieve the login password stored in SQLCA.logpass using the process hacker tool. He asks us to secure this.

How can we do this?

Thank you in advance.

Pierre

Andreas Mykonios Accepted Answer Pending Moderation
  1. Wednesday, 27 April 2022 10:17 AM UTC
  2. PowerBuilder
  3. # 1

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.

Comment
There are no comments made yet.
Andreas Mykonios Accepted Answer Pending Moderation
  1. Wednesday, 27 April 2022 10:39 AM UTC
  2. PowerBuilder
  3. # 2

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

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 27 April 2022 15:48 PM UTC
  2. PowerBuilder
  3. # 3

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

 

Comment
  1. René Ullrich
  2. Thursday, 28 April 2022 04:58 AM UTC
I think it is a good way to make it more difficult to get the password. But it is still possible because at some moments the password is available unencrypted in memory. I don't know if it is possible at all to make it secure. If there is a way it have to be provided by PowerBuilder (e.g. secured variables)



Currently you can only change your application architecture (3-tier) to make it secure.
  1. Helpful 3
  1. Arnaud PLOUCHART
  2. Tuesday, 17 May 2022 13:20 PM UTC
Hi all,

I apply your method:



SQLCA_TRAD.of_connect( SQLCA_TRAD) // CONNECT USING SQLCA_TRAD;

function of_connect() contain:

This.of_decrypt(as_transaction )

Connect using This;

This.of_encrypt(as_transaction )



But i have one line in ProcessHaker with my password clear.



If i DESTROY SQLCA_TRAD;

This line with my password in processhacker disappear.

But I don't want to destroy my transaction object to no longer see the password.

How to do?



Regards
  1. Helpful
  1. Roland Smith
  2. Wednesday, 18 May 2022 13:13 PM UTC
See my full answer. You and the hacker are the same person so of course you recognize the password. Does the Process Hacker app indicate that the string is a password?
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 27 April 2022 20:06 PM UTC
  2. PowerBuilder
  3. # 4

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

Comment
  1. Pierre DETE
  2. Thursday, 28 April 2022 08:57 AM UTC
Hi Miguel, we are using Oracle and finalizing QA tests for Postgres.
  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 28 April 2022 11:43 AM UTC
Okay, by default, Oracle encrypts user and password when sending over the network to the db server. However, if the hacking tool does memory dumps, there will be a moment the user and password can be read. To be fair, the moment anyone can do a memory dump on your PC, you're in a lot more trouble than just finding the password of SQLCA.

Maybe the security should be that "no one can run such a tool on your PC or SERVER"...

This lady will tell you more on memory dumps: https://www.youtube.com/watch?v=-8f8avZ2V7s

regards.

  1. Helpful
There are no comments made yet.
Rachid Sbaibi Accepted Answer Pending Moderation
  1. Thursday, 28 April 2022 08:52 AM UTC
  2. PowerBuilder
  3. # 5

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.

Comment
  1. Miguel Leeuwe
  2. Thursday, 28 April 2022 11:45 AM UTC
Good practice, but the moment the user types in his password, that type stuff will be in memory, at least for some time. That's the problem with memory dumps if I've understood some experts.

regards.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 28 April 2022 14:59 PM UTC
  2. PowerBuilder
  3. # 6

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.  

Comment
  1. Pierre DETE
  2. Wednesday, 18 May 2022 16:18 PM UTC
We were able to capture the password in an array by catching it letter by letter to avoid it being present in clear text in memory, unfortunately we were blocked by the transaction object which kept the login information visible even if we change it right after CONNECT. :(
  1. Helpful
  1. Chris Pollach @Appeon
  2. Wednesday, 18 May 2022 16:45 PM UTC
Hi Pierre;

It's a simple fix IMHO ... Just encrypt the Transaction Object. Have a look at my example already posted as a reply in this thread. ;-)

Regards ... Chris
  1. Helpful
  1. Roland Smith
  2. Thursday, 19 May 2022 14:37 PM UTC
I think the whole issue is blown out of proportion. The person reviewing the memory dump has two pieces of information that a hacker would not: They know what the password is and they know how PowerBuilder works.
  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 17 May 2022 21:42 PM UTC
  2. PowerBuilder
  3. # 7

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

Comment
  1. Pierre DETE
  2. Wednesday, 18 May 2022 16:12 PM UTC
Hi John,

Thank you for this method which I did not know but which implies a complete rewriting of the connection method. We prefer to avoid it.
  1. Helpful
  1. John Fauss
  2. Thursday, 19 May 2022 03:57 AM UTC
How do you know much coding effort it will take to retrofit if you don't investigate it? It could be very simple, at least it is with SQL Server (again, I don't know Oracle). You asked for possible ways to address a potential security vulnerability, then dismiss what looks at first glance like a viable and promising solution. I'm sorry this wasn't the answer you were looking for. Best wishes and good luck!
  1. Helpful 2
  1. Pierre DETE
  2. Thursday, 19 May 2022 16:47 PM UTC
Hi John, sorry for my too fast reply, our application KTP is like a dinosaur with over 100 customers, more than 20 years of existence and many versions to maintain, so we cannot afford to impose such changes on our customers. As an evolution we are finalizing the UAA connections with OKTA and KEYCLOAK compatibility. But for this particular problem, one of our customers is reporting it as a bug, and we are looking for faster solutions and answers.

Best regards.
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Wednesday, 18 May 2022 13:09 PM UTC
  2. PowerBuilder
  3. # 8

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. 

Comment
  1. Pierre DETE
  2. Wednesday, 18 May 2022 16:14 PM UTC
Hi Roland,

With all our tests, we can now confirm that the transaction object used to connect is kept into memory, even if change it after CONNECT. Very bad news.
  1. Helpful
  1. Brad Mettee
  2. Thursday, 19 May 2022 13:54 PM UTC
Pierre,

I think you're missing the point here. What Roland says is more important than the information remaining in memory. Physical security of the machines, and prevention of virii/trojans/malware, is just as important as keeping memory clean.



When a user inputs a password (or any other "important" information), it will always exist somewhere in memory. That can't be bypassed, ever. The situation you're describing, of having a password lay in memory, is always going to occur at some point. The fact that it's not immediately cleared after the connect isn't anything out of the ordinary.



Since you know what you're looking for in memory, how hard would it be to find the same information for a scanning program? Does anything around the password indicate that it's a password field? Is the memory formatted in some specific way that makes it obvious that it's a password?



As long as there's a chance of foreign software being run on the PC, you'll always have the possibility of a password being stolen. It doesn't have to lay in memory for it to happen; a keylogger, windows input field scraper, tcpip scanner, etc. are all ways to snag data that are just as dangerous as a memory scanner.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.