- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
The programs I run often require a password which usually comes in the form of a macro variable that can then be printed to the log window. Log windows may be saved for audits.
We use SQL pass-through mostly for speed considerations.
I am wondering if SAS would consider puting an option on the %let statement to keep certain macro variables from printing.
It is done in SAS Stored procedures for variables named <something>_password.
Sumner
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Does this help you?
http://support.sas.com/resources/papers/proceedings09/013-2009.pdf
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Before the statements revealing that mVar use statements
%let oldopts =
%sysfunc( getoption( mprint))
%sysfunc( getoption( Symbolgen))
%sysfunc( getoption( mLogic))
;
option NOmprint NOsymbolgen NOmlogic ;
After the statement that (no longer) reveals the password, use this statement to reinstate any macro debugging:
Option &oldopts ;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I need the symbolgen mlogic mprint on for the log files audits.
Symget was something I tried in the past and it didn't work.
I want a property to be on the macro variable that makes it so SAS knows the macro variable should not be printed versus using a different method of calling the macro variable. This may not be possible as macro variables are plain text with no real inherent properties.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
shwilliams4
you wrote:
I need the symbolgen mlogic mprint on for the log files audits.
.
expecting this "need" I offered you two statements - one to retrieve the current settings before masking the password, and one to reinstate after.
You suggest something which might be possible. Create an IDEA.
peter.C
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for contribution, Reeza. I also linked a document by Carpenter dealing with the issue of masking passwords. Was hoping the OP would read it and see if there was anything useful there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
All great ideas I have aexplored. Peter C. lead me down the path of Creating an Idea which is more of what I needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
has a box of ACTIONS on the right
the last of these is
create an IDEA
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Proc pwencode comes fairly close to what you need for the moment, as it keeps your password from appearing in the log.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Not really. Having the encrypted password in the log does not make it secure.You are corect that one does not know the password, but they don't need to know the password in order to get into the system.
Internally we lock our databases down to protect PHI and Employee PHI. Having the encrypted password go into a log means someone without access to EPHI can use that login/encrypted password to see EPHI. This user would be internal to the company with access to every system.
While {sas02}A48sdgkjsdhkljer may seem secure because you can't see the original password, that encrypted password can still be used to get access to the system. A log file that says password = ********** is secure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
There are methods to deal with this.
One is better coding to turn off MPRINT, SYMBOLGEN while dealing with the password.
.
Another is better methods of connecting using SAS BI tools so that passwords are not stored in macro variables.