Smalltalk › Instantiations

userid and password in plain text in walkback files

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Lloyd Lisk

userid and password in plain text in walkback files

Hi folks.

We are currently running v8.5.2, but have had this app in SmallTalk since the last millennium. I‘ve been sifting through walkback files and noticed that there are instances where the user’s userid and password are displayed in plain text in the walkback. In today’s SOX compliant world, that’s a no-no.

Has anyone dealt with this issue in the past?

Any recommendations for remediation?

Thanks in advance……Lloyd

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

jtuchel

Re: userid and password in plain text in walkback files

just an idea: what about overriding debugPrintOn: for the objects that contain passwords?

Joachim

Am Montag, 7. Oktober 2013 18:03:07 UTC+2 schrieb Lloyd Lisk:

Hi folks.

We are currently running v8.5.2, but have had this app in SmallTalk since the last millennium. I‘ve been sifting through walkback files and noticed that there are instances where the user’s userid and password are displayed in plain text in the walkback. In today’s SOX compliant world, that’s a no-no.

Has anyone dealt with this issue in the past?

Any recommendations for remediation?

Thanks in advance……Lloyd

Louis LaBrunda

Re: userid and password in plain text in walkback files

In reply to this post by Lloyd Lisk

Hi Lloyd,

I use #xteaEncryptWithKey: and #xteaDecryptWithKey: from TEAEncryptionApp to encrypt things. With a little work you can compare the encrypted values and not have the raw values around too much.

Lou

On Monday, October 7, 2013 12:03:07 PM UTC-4, Lloyd Lisk wrote:

Hi folks.

We are currently running v8.5.2, but have had this app in SmallTalk since the last millennium. I‘ve been sifting through walkback files and noticed that there are instances where the user’s userid and password are displayed in plain text in the walkback. In today’s SOX compliant world, that’s a no-no.

Has anyone dealt with this issue in the past?

Any recommendations for remediation?

Thanks in advance……Lloyd

Steven LaFavor

Re: userid and password in plain text in walkback files

In reply to this post by jtuchel

I currently work with Lloyd Lisk, and I don't think that overridding debugPrintOn: will do the trick.

The information that comes back in a walkback.log file is a dump of all the messages in the stack, along with all of the keyword arguments and method temporaries for those messages, as shown in the snippet below:

....stuff omitted.....

TOPODBCDatabaseAccessor>>#sqlConnect:user:password:ifError:
receiver = TOPODBCDatabaseAccessor(using a TOPDB2Interface)
arg1 = 'OUR_DATABASE'
arg2 = 'APP_USERID'
arg3 = 'APP_PASSWORD'
arg4 = [] in TOPODBCDatabaseAccessor>>#connectUserName:password:serverName:databaseName:dataSourceName:ifError:
temp1 = -1
TOPODBCDatabaseAccessor>>#connectUserName:password:serverName:databaseName:dataSourceName:ifError:
receiver = TOPODBCDatabaseAccessor(using a TOPDB2Interface)
arg1 = 'APP_USERID'
arg2 = 'APP_PASSWORD'
arg3 = ''
arg4 = 'OUR_DATABASE'
arg5 = 'OUR_DATABASE'
arg6 = [] in MAPExceptionHandler class>>#databaseErrorBlock:offendingObject:

.....and more stuff omitted.....

Looking for some ideas if anyone else has tackled this sort of thing before.

*Steve*

jtuchel

Re: userid and password in plain text in walkback files

...and as far as I can tell from looking into places that get visited by outputWalkback:, all the arguments and stuff represent themselves on the stack by debugPrint, which, ultimately is implemented in debugPrintOn: So I guess it is worth a try. Takes about 2 minutes.

Am Montag, 7. Oktober 2013 23:27:23 UTC+2 schrieb Steven LaFavor:

I currently work with Lloyd Lisk, and I don't think that overridding debugPrintOn: will do the trick.

The information that comes back in a walkback.log file is a dump of all the messages in the stack, along with all of the keyword arguments and method temporaries for those messages, as shown in the snippet below:

....stuff omitted.....

TOPODBCDatabaseAccessor>>#sqlConnect:user:password:ifError:
receiver = TOPODBCDatabaseAccessor(using a TOPDB2Interface)
arg1 = 'OUR_DATABASE'
arg2 = 'APP_USERID'
arg3 = 'APP_PASSWORD'
arg4 = [] in TOPODBCDatabaseAccessor>>#connectUserName:password:serverName:databaseName:dataSourceName:ifError:
temp1 = -1
TOPODBCDatabaseAccessor>>#connectUserName:password:serverName:databaseName:dataSourceName:ifError:
receiver = TOPODBCDatabaseAccessor(using a TOPDB2Interface)
arg1 = 'APP_USERID'
arg2 = 'APP_PASSWORD'
arg3 = ''
arg4 = 'OUR_DATABASE'
arg5 = 'OUR_DATABASE'
arg6 = [] in MAPExceptionHandler class>>#databaseErrorBlock:offendingObject:

.....and more stuff omitted.....

Looking for some ideas if anyone else has tackled this sort of thing before.

*Steve*

sjmclaurin

Re: userid and password in plain text in walkback files

We ran into this exact problem in our product when I implemented LDAP. It was not just a problem in a walkback, it was also a security concern when the value was being passed across the network. What I did is create a wrapper object for the user ID and password strings. This object encrypts and decrypts the string, however it is stored in an instance variable in an encrypted String form. When the object is printed out on a walkback, that is what is seen - the encrypted string. The object implements a method that will return the decrypted value, which I only use right before authentication to limit exposure to values in the clear.

Another tip for such an object is to have your encryption to append a header and trailer to the encrypted value so you can identify when creating the object whether the value is already encrypted (and possibly how it is encrypted, this helps if you store encrypted values and down the road change your encryption method) and also a method to pull out the raw encrypted String. This lets you send just the data across the wire and not run into potential remote reference issues. Something like this:

EncryptedString

value = |encryptedaes|asdk65q35jasg8oy44t|encryptedaes|

You would have a class side constructor that takes a new string, identifies whether it is already encrypted the way you desire and either store it or encrypt then store it in the new instance's variable. Then you have a couple methods to handle getting the value out (and some internal other methods to do the encryption work).

EncryptedString class>>on: aString

"Answer a new instance with the stored encrypted value."

^ <does string have encrypted header/trailer>

ifTrue: [ self new value: aString; yourself ]

ifFalse: [ self new encrypt: aString; yourself ]

EncryptedString>>value

"Answer the encrypted value."

^ value

EncryptedString>>decryptedValue

"Answer the decrypted value."

^ self decrypt: value